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AESTRACT 

In  197U,  the  Naval  Supply  Systems  Command  initiated 
actions  to  automate  the  procurement  process  within  the  Navy 
Field  Contractina  System  (NFCS).  The  development  proiect 
was  titled.  Automation  of  Procurement  and  Accounting  Data 
Entry  (APADE)  .  By  1979,  the  original  project  was  discon- 
tinued and  a  redesign  effort  was  initiated.  In  an  effort  to 
determine  the  underlying  reasons  for  the  project1 s  delay  and 
problems  encountered  in  developing  an  Automated  Data  System 
(ADS),  this  thesis  examines  the  APADE  project.  In  addition 
to  the  reasons  and  probLems  addressed  by  the  Naval  Data 
Automation  Command's  evaluation  report,  the  researcher 
concluded  that  the  procurement  procedures  utilized  by  the 
NFCS  activities  were  not  defined  nor  standardized  suffi- 
ciently to  facilitate  ADS  development.  Additionally,  there 
was  no  indication  that  this  situation  was  addressed  or 
corrected  during  the  planning  phase  of  APADE  II  development. 
The  researcher  also  concluded  that  various  environmental 
conditions  significantly  impacted  upon  the  development 
process. 
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I.   INTRODUCTION 

A.  NAVAL  FIELD  CONTRACTING  SYSTEM  MISSION 

The  Naval  Supply  Systems  Command's  (NAVSCFP)  charter 
specifically  assigns  them  with  the  responsibility  for  the 
procurement  of  material  and  services  throughout  the 
Department  of  the  Navy  except  as  otherwise  delegated  by 
higher  authority.  Included  within  this  procurement 
authori+y  is  the  management  responsibility  for  the  Navy 
Field  Contracting  System  (NFCS).  The  NFCS  consist  of  field 
activities,  located  at  various  Naval  facilities,  with  dele- 
gated procurement  authority  of  various  monetary  thresholds. 
It  is  with  the  field  activities  that  the  ultimate  responsi- 
bility of  satisfying  all  the  fleet  purchase  request  depends. 

It  is  the  inherent  overall  mission  cf  the  NFCS  to 
provide  effective  and  efficient  procurement  services  to 
fleet  units  and  Naval  Shore  activities.  This  service 
includes  supplying  locally-procured  standard  items,  non- 
standard material,  and  other  servioes.  Effective  perfor- 
mance cf  the  procurement  function  consists  of  providing  the 
customer  the  material  or  service  requested  at  tie  time  it  is 
needed  and  at  the  best  possible  price. 

B.  3ACKGR0UND 

Over  the  last  decade,  a  major  criticism  of  the  Navy 
Field  Contracting  System  has  been  inadequate  procurement 
response  time  (the  time  elapsing  from  submission  of  the 
end-use  requisition  to  delivery  cf  the  needed  material  or 
service).  During  the  early  1970s,  the  Naval  Supply  Systems 
Command    (NAVSUP)         became   aware      of    several      common    problems 


which  surfaced  during  studies  conducted  on  the  procurement 
process.   They  were: 

1.  Lack  of  standardization, 

2.  Untimely  status  Inf or mation, 

3.  Inflexible  management  reports,  and 

4.  Interface  only  with  hard  copy  documents. 

All  of  these  problems  impacted  upon  the  total  responsiveness 
of  the  procurement  process  and  directly  affected  the  mission 
capability  of  the  NFCS. 

In  1974,  as  a  direct  result  of  ^hese  studies,  NAVSUP 
initiated  actions  to  automate  the  procurement  process  at  the 
major  NFCS  activities.  These  are  oomprised  of  the  Naval 
Supply  Centers  (NSC)  and  Naval  Regional  Contracting  Centers 
(NRCC).  NAVSUP  envisioned  a  system  that  would  overcome  the 
deficiencies  and  enhance  the  response  time  of  the  procure- 
ment process. 

The  automated  system's  major  objectives  would  be  to: 

1.  Automate  the  procurement  document  preparation, 

2.  Management  tracking, 

3.  Control  of  non-standard  requisition  documents, 

4.  Status  reports  to  customers, 

5.  Generate  management  statistics  and  reports,  and 

5.   Automate  the  interface  with  the  accounting  functions. 

In  April  of  1975,  a  research  and  development  project,  APADF 
I  (Automation  of  Procurement  and  Accounting  Data  Entry),  was 
initiated.  Although  the  RSD  effort  net  with  limited  sucess, 
it  demonstrated  a  definite  need  to  automate  the  procurement 
process.  3y  1977,  NAVSUP  directed  that  system  development, 
APADE  II,  be  initiated  with  a  total  system  package  scheduled 
for  completion  on  April  of  1979. 
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In  November  1979 ,  with  only  partial  development  and 
implementation  at  two  prototype  sites  completed,  the  Chief 
of  Naval  Operations  recommended  to  NAVSUP  that  further 
development  and  implementation  be  discontinued  until  the 
Automated  Data  System  (ADS)  plan  was  rewritten  and  hardware 
requirements  analyzed.  The  new  development  effort  was  to  be 
accomplished  in  accordance  with  the  current  directives  on 
the    Navy's    Automated    Data   System    Program. 

C.  OBJECTIVE 

It  is  intended  that  the  presentation  of  this  Thesis  will 
serve  three  major  objectives. 

First,  through  the  presentation  of  a  documented  record 
of  the  major  efforts  to  automate  the  procurement  process 
within  the  NFCS,  the  underlying  reasons  for  the  projects 
delay  and  the  problems  cited  by  the  Naval  Data  Automation 
Command's  project  evaluation  rs port  will  surface. 

Secondly,  and  perhaps  more  importantly,  by  describing 
the  various  phases  of  development  of  the  APADE  project  and 
comparing  them  to  a  recommended  ADS  development  process, 
valuable  insight  of  the  prcolems  involved  in  designing, 
developing,  and  implementing  an  automated  system  will 
promote  improved  managerial  decisions  concerning  automation. 

The  final  objective  is  to  contribute  an  overall  benefit 
by  presenting  a  documented  historical  record  of  the  events 
to  facilitate  the  current  automation  effort  of  the  procure- 
ment process. 

D.  SCOPE 

The  effort  to  automats  the  NFCS  procurement  process  has 
covered  a  minimum  of  eight  years.  Over  that  time  period, 
there  have  been  seven  commands   within  the  Department  of  the 
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Navy,  four  private  contractors  aid  the  General  Service 
Administration  (GSA)  associated  with  the  project  in  one  form 
or  another.  It  is  impossible  to  record,  within  a  reasonable 
amount  of  time,  all  of  the  correspondence  and  documentation 
which  transpired  during  that  period.  Accordingly,  this 
study  examines  the  key  documentation  and  correspondance 
submitted  and  received  by  the  Fleet  Material  Support  Office 
(FMSO),  in  the  role  as  Central  Design  Aaency  for  the 
project;  the  GSA  involvement;  the  role  of  NA7SQ?  as  the 
project  manager;  and,  finally,  the  utilization  of  a  private 
contractor   to    design,    develop,    and   implement    the    system. 

Additionally,  to  provide  a  sound  basis  from  which  to 
examine  the  automation  effort,  this  paper  will  initially 
focus  on  two  specific  areas.  The  first  area  to  be  examined 
will  be  the  role  of  the  flFCS  and  th  =  procurement  process  at 
the  major  activities.  The  second  area  will  be  the  evolution 
of  the  Navy's  Automated  Data  System  program  and  applicable 
regulations    in    effect    daring   the    automation    effort. 

E.   METHODOLOGY 

The  research  of  the  subject  was  first  initiated  after  a 
telephone  conversation  with  the  Elxscutive  Officer,  Fleet 
Material  Support  Office  (FMSO)  Mechancisburg,  Pennsylvania  on 
23  February  1982  indicated  that  the  researcher's  next  duty 
assignment  would  be  at  F^SO  as  the  .\PADE  project  officer. 
The    Executive   Officer      stated   that    a    historical      research   of 


the    APADE    effort      could    provide    valuable    lessen; 


for    future 


managers  of  the  Navy's  resources  in  addition  to  providing 
the  researcher  with  the  required  insight  to  assume  the  new 
duties. 

Data  was  collected  on  three  levels;  (a)  field  research 
at  Naval  Supply  Center  Dakland,  FMS3,  and  Naval  Supply 
Systems    Command,    Washington    D.C.;       (b)     Discussions    and    phone 
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conversations  with  various  agency  personnel;  (c)  research  as 
indicated   in   the   list    of   references. 

F.       THESIS    ORGANIZATION 

The  format  described  in  the  table  of  contents  was  chosen 
because  it  seems  to  present  the  material  in  a  logical 
sequence.  Chapter  One  is  the  introduction  and  consists  of  a 
brief  discussion  of  the  automation  effort  with  the  scope  and 
objective      of      the      research   effort.  The      methodology      of 

collecting  the  data  is  also  provide! .  The  next  chapter  is 
devoted  to  the  discussion  3f  the  role  of  the  MFCS  within  the 
NAVSUP  organization.  A  detailed  explanation  of  the  procure- 
ment process  and  the  problems  encountered  are  also 
presented.  Chapter  Three  provides  the  reader  with  insight 
of  the  Navy's  ADP  Program,  its  objectives  and  the  laws  and 
regulations      that   control      it.  The      fourth   chapter      is      a 

detailed  analysis  of  the  alternation  effort  as  examined  from 
various  correspondance,  files,  publications  and  interviews. 
Chapter  Five  discusses  the  NAVDAC  evaluation  and  constraints 
placed  on  the  project  by  the  CNO.  Chapter  Six  contains  the 
researcher's   conclusions. 
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II.   NAVY  EI2LD  CONTRACTING  SYSTEM 

As  mentioned  in  the  introduction,  to  facilitate  the 
examination  of  the  effort  to  automate  the  procurement 
process  within  the  Navy  Field  Contracting  System  (NFCS)  ,  it 
is  essential  to  first  focus  on  the  organizational 
characteristics  and  functional  requirements  of  the  system. 

A.   BACKGROUND 

The  Navy  Field  Contracting  System,  under  the  cognizance 
of  the  Naval  Supply  Systems  Command  (NAVS3P) ,  consists  of 
ail  contracting  offices  of  Naval  activities  except  the 
following: 

1.  Automatic  Data  Processing  Selection  Office, 

2.  Office  of   Naval  Research  its   Branch  Offices   and  its 
Resident  Representatives, 

3.  Military  Sealift  Command  and  its  field  activities, 

i*.   Marine  Corps  and  its   field  activities;   however,   its 

air  stations  are  a  part  of  the  NFCS, 
5.   Headquarters,   Naval   Air  Systems  Command,    its  Naval 

Plant  Representatives   Offices  and  its   Naval  Aviation 

Logistic  Center,  Commercial  Rework  Department, 
5.   Headquarters,   Naval   Sea  System   Command,   its   Naval 

Plant   Representative  Offices   and   its  Supervisor   of 

Shipbuilding,  Conversion  and  Repair, 
7.   Headquarters,  Naval  Electronic  System  Command, and 
3.   Headquarters,  Naval  Facilities  Engineering  Command  and 

its  field  activities  [Ref.  1:  p.  1-40 1. 51b]. 
In  total,   the  NFCS  is   comprised  of  several  hundred  indivi- 
dual activities,    each  having  a   liait  to   their  purchasing 
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authority      as        perscribed      by      ths      Naval        Supply      Systems 
Command  (NAVSUP)  . 

Centralized  control  is  provided  by  the  establishment  of 
nine  geographical  procurement  regions  throughout  the  world. 
Six  of  the  regions  are  located  within  the  Continental  U.S. 
with  the  remaining  three  being  Hawaii,  Far  East,  and  Europe. 
Each  region  has  a  Naval  Supply  Canter  (NSC),  Naval  Supply 
Depot  (NSD)  ,  or  Naval  Regional  Contracting  Center  (NRCC)  , 
formerly  known  as  Naval  Regional  Contracting  Office  (NRCO)  , 
designated  as  the  cognizant  contracting  office  for  that 
region.  It  is  within  this  organizational  framework  that 
NAVSUP  centralizes  the  buying  by  region,  area,  or  commodity 
to   the   maximum   extent    possible. 

3.       CATEGORIES    OF    PURCHASING    ACTIVITIES 

NAVSUP      categorizes      purchasing   activities      by      defining 
them    by   the      type   of   authority   and      responsibility    they    have 
with    respect    to    purchasing.         The    three    categories    are:       (1) 
central   buying,         (2)       ncncentral   bu?ing,      and      (3)       limited 
buying. 

1  •      Central    3uvj.n  s 

There  are  three  iiffs-rent  levels  of  centralized 
buying.  The  first  level  is  regional  buying.  Ihe  activites 
designated  for  regional  buying  are  the  NSC's  and  NRCC's. 
They  are  responsible  for  baying  item-  assigned  by  NAVSUP  and 
for  making  purchases  which  exceed  ^he  limited  purchase 
authority  of  the  activities  within  thsir  jurisdiction.  In 
addition,  for  activities  designate!  as  the  regional 
contracting  office  for  thsir  region,  the  responsibility  op 
assisting  NAVSUP  in  meeting  the  functional  and  nonfunctional 
management  reguiremer.  ts  is  assigned.  This  includes,  but  is 
not    limited   to: 
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1.  Providing  guidance  aid  technical  assistance, 

2.  Evaluating  staffing,  performance,  and  effectiveness  of 
NFCS  contracting  offices, 

3.  Determining  compliance  with  applicable   priorities  of 
law  and  regulations,  and 

4.  Assigning   contracting   officer    authority   for   NFCS 
activities  and  personnel. 

The  second  level  of  centralized  buying  is  area 
buying.  These  are  Navy  field  activities,  designated  by 
NAVSUP,  responsible  for  purchases  which  are  in  excess  of  the 
contracting  authority  granted  to  other  Naval  activities 
located  within  a  particluar  area.  Currently,  there  are 
seven  area  buying  activities  located  within  the  Continential 
U.S.   They  are: 

1.  Naval  Air  Station,  Jacksonville,  Fla., 

2.  Naval  Air  Station,  Pensacola,  Fla., 

3.  Naval  Air  Station,  Corpus  Christi,  Tx., 

4.  Naval  Shipyard,  Portsmouth,  N.H., 

5.  Naval  Supply  Canter,  Pugat  Sound,  Wa., 
5.  Naval  Supply  Center,  San  Diego,  Ca. ,  and 

7.  Supply  Department,  Naval  Administrative  Command,  Naval 
Training  Center,  Sreat  Lakes,  111. 
Additionally,  the  area  buyina  activities  will  make  purchases 
which  are  within  the  authority  of  the  activities  they 
service  when  it  is  advantageous  due  to  complexity  of  the 
purchase  or  their  additional  capabilities  are  required. 

The  third  level  of  centralized  buying  is  commodity. 
This  level  of  buying  is  only  performed  by  the  NAVSUP  managed 
inventory  control  points (I CP's) .  Purchasing  by  ICP's  is 
usually  for  new  stock  requirements  and  system  stock  replen- 
ishment for  support  cf  major  systems  throught  the  Navy.  The 
activities  designated  as  inventory  contol  points  are: 
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1.  Navy  Aviation  Supply  Office, 

2.  Navy  Ships  Parts  Control  Center,  and 

3.  Navy  Resale  and  Service  Support  Center. 

2.   Ncncentral  Buying 

In  general,  activities  designated  as  noncentral 
buying  activities  are  responsible  for  buying  supplies  and 
services  in  support  of  their  assigned  mission  as  well  as  for 
local  use.  Purchases  are  a  ade  within  the  monetary  limits  as 
imposed  by  NAVSUP.  Examples  of  noncentral  buying  activities 
are:  Naval  Shipyards,  Naval  Air  Development  Centers,  Naval 
Weapons  Centers,  and  Naval  Construction  Battalions.  The 
imposed  purchase  limitation  is  usually  $100,300  with  the 
exception  of  Naval  Shipyards  engaged  in  the  Naval  Nuclear 
Propulsion  Program.  They  have  unlimited  purchase  authority 
within  their  mission  area. 

3  •   Limited  Buy,in .g 

Limited  baying  activities  are  those  designated  in 
writing  by  NAVSUP  assigning  purchase  authority  and  types  of 
purchases  allowed.  Examples  of  these  activities  are 
Commissary  Stores,  Naval  Reserve  Office  Training  Corps,  and 
Naval  Health  Sciences  Education  and  Training  Conmand. 

C.   PROCUREMENT  PROCESS 

For  the  purpose  of  analyzing  the  procurement  process 
within  the  NFCS,  attention  will  be  focused  on  the  regional 
baying  activities  (NSC  and  NRCC) .  The  reason  for  analyzing 
the  procurement  process  at  the  NSC  and  NRCC  is  two-fold. 
First,  the  majority  of  the  automation  effort  has  concen- 
trated on  analyzing  the  procurement  process  at  the  regional 
buying  activities  due  to  the  large  volume  in  procurement 
actions.    Secondly,   it  provides   a  better  understanding  of 
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the  magnitude  and  scope  of  the  overall  procurement  process 
in  the  NFCS  by  examining  the  organization  and  functions  of 
these  two  activities. 

1 .   NSC  and  NRCC  Org.ani zati on 

although  the  NSC' s  and  NRC3f3  are  responsible  for 
performing  the  same  procurement  mission  and  governed  by  the 
same  purchase  regulations,  there  is  a  significant  difference 
in  their  organizational  composition  to  accomplish  that 
mission.  The  NSC  procurement  component  functions  as  a 
department  within  that  activity  as  contrasted  to  the  autono- 
mous NRCC.  These  relationships  are  exhibited  by  Figures  2.1 
and  2.2. 

a.   NSC  Purchase  Department 

The  purchase  department  in  the  standard  NSC  is 
comprised  of  three  separate  divisions  which  share  the 
overall  responsibility  to  plan  and  conduct  purchase  and 
contract  administration  operations  for  the  activity.  The 
following  is  a  brief  discussion  of  those  divisions'  respon- 
sibilities within  the  organization. 

3uying  and  Order  Division 

The   Buying  and   Order   Division  is   responsible 

for: 

1.  Reviewing   purchase    re  guest, 

2.  Determining   types    and    methods    of    purchase, 

3.  Reviewing   Qualifications    of    contractors, 

4.  Performing   bid    analysis, 

5.  Performing  negotiations  with   contractors,    and 

6.  Placing    orders    under    established    federal   contracts. 
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Figure   2.1         Standard   Organ  izatrions   for    NSC   and   Depots 
(NAVSOP    Man.    7ol.I) 


Purchase   Service   Division 

The  Purchase  Service  Division  is  responsible  for 
preparing  and  issuing  ill  invitations  for  bids  and  reguest 
for  proposals  as  directed  by  the  buying  and  order  division. 
In  addition,  they  maintain  records  of  bids  received,  assign 
purchase  reguest  to  cognizant  buyers,  prepare  and  issue  ail 
contractual  documents,  maintain  control  records,  and  prepare 
statistical   procurement    reports. 
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Figure  2.2    Standard  Organization  far  NRCCs  (NAVSUP  Man, 
701.1) 


Contract  Administration  Division 

This  division  is  responsible  for  administration 
of  the  contract  once  it  is  awarded.  They  issue  change 
orders  and  obtain  written  acceptance  of  contractors  to 
amendments  and  modifications.  Additional  responsibility 
includes: 
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1.  Amend,  modify,  and  terminate  contracts  due  to  default; 

2.  Collect,  assemble,  analyze,   and  promulgate  contractor 
performance  data;  and 

3.  In  cases  of  delinquent  deliveries,   effect  contractor 
discipline. 

b.   NRCC  Purchase  Organization 

As  previously  mentioned,  the  NRCC's  carry  out 
their  assigned  mission  as  a  completely  autonomous  organiza- 
tion. However,  like  the  NSC's,  they  have  three  divisions 
that  share  in  the  responsibilities  of  that  mission. 

Field  Management  Division 

This  division  provides  the  purchase  management 
guidance,  assistance,  and  advise  to  the  NFCS  activities 
within  their  cognizant  regional  areas  as  deleaa-'-.ed  by 
NAVSDP.  The  general  duties  of  the  division  are  comprised  of 
•'-he  following: 

1.  Appraise  organization  and  staffing, 

2.  Evaluate  levels  of  contracting  authority, 

3.  Administer   and   coordinate    purchasing    training 
programs, 

^.   Prescribe  standard  operating  procedures, 

5.  Advance  planning, 

6.  Analyze  purchase  statistics,   trends,    workloads  for 
management  effectiveness,  and 

7.  Determine   the  need   for    indefinite  delivery   type 
contracts  for  common  type  item=. 

Administrative  and  Planning  Division 

The  administrative  and  planning  division 
performs  administrative,  planning,  personnel,  office 
service,  and  purchase  support  services  such  as: 
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1.  Analyzing  internal  operating  methods, 

2.  Administering  various  management  improvement  programs, 

3.  Estimating  budget  and  personnel  ceiling  requirements, 

4.  Preparing  and  maintaining  administrative  directives, 

5.  Providing  mail,  filing,  and  duplicating  services, 

6.  Screening,    recording,    and    routing   all   incoming 
purchase  request, 

7.  Preparing  and   mailing  invitation  for  bids   (IFB)   and 
request  for  proposals  (HFP) , 

8.  Maintaining  contract  files, and 

9.  Preparing  external  statistics   and  procurement  reports 
for  the  activity. 

Purchase  Division 

The  purchase  division  of  the  NRCC  plans  and 
conducts  the  purchase  and  contract  administration  functions 
for  the  activity.  That  responsibility  includes  the 
following: 

1.  Reviews  purchase  request  for  correctness, 

2.  Analyzes  and  evaluate  bids  and  proposals, 

3.  Directs  the  issuance  of  IF3S  and  RFPs, 

4.  Conducts  contract  negotiations, 

5.  Participates  in  pre- a  ward  surveys, 

6.  Determines  contractor  responsibility,    capacity,   and 
performance  status, 

7.  Determines  when  to  award,  amendment,  claim,  and  termi- 
nate contracts,  and 

8.  Performs  contract  administration  functions. 

2.   NSC  and  NRCC  Procurement  Pro z ess 

Basically,  the  overall  procurement  missions  of  the 
NSC's  and  NRCC»s  are  identical.  They  are  both  responsible 
for  satisfying   the  purchase  requirements  of   the  fleet   as 
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well  as  all  purchase  requirements  exceeding  the  limited 
purchase  authority  of  other  Navy  shore  activities  within 
their  cognizant  geographical  region.  They  have  both  been 
granted  unlimited  purchase  authority  by  NAVSUP.  The  infor- 
mation requirements,  regulations,  functions,  and  procedures 
of  the  NSCs  and  NRCCs  to  carry  out  these  responsibilities 
are  governed  by  the  Defense  Acquisition  Regulations  (DAR)  , 
Navy  Contracting  Directives,  the  NAVSUP  Fieli  Purchasina 
Manual  (NAVSUP  P-U67)  ,  NAVSUP  policy  guidance,  and  locally- 
developed   instructions. 

Although  the  NSC' =  and  NRCCs  are  organizationally 
different,  the  basic  procurement  functions  of  these  activi- 
ties are  sufficiently  similar  to  be  described  by  one  gener- 
alized information  flow.  This  is  graphically  displayed  by 
Figure   2.3. 

Processing  starts  with  the  receipt  of  a  purchase 
request  at  the  procurement  office.  Requisitions  are  usually 
received  in  the  form  of  a  hard-copy  document  cr  punched 
card.  Specifications,  drawings,  an  1  other  supporting  docu- 
mentation will  be  provided  as  required.  A  control  desk  is 
usually  established  to  manually  log-in  each  document  by 
requisition  number,  date  received,  dollar  value,  and 
description.  The  requisitions  are  then  sorted  according  to 
a  customer  assigned  priority  number.  They  are  screened  for 
completeness,  consolidated  when  appropriate,  assigned  a 
Control  Number,  and  placed  in  folders.  The  control  desk 
determines  the  commodity  and  assigns  the  appropriate  buyer 
or  organizational  code  depending  cr.  local  criteria.  The 
buyer  receives  the  requisition  and  reviews  it  for  compiet- 
ness    and   accuracy. 

At  this  point,  the  next  procedure  depends  on  the 
estimated      value      of      the    procurement      action.  For      small 

purchases,    under    $10,000    (Changed   to    $25,000    in    April    1982), 
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Figure  2.3    Procurement  Process  (Ref.  2) 
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the  buyer  will  issue  a  Request  For  Quote  (HFQ)  or  obtain  an 
oral  quotation  since  the  regulations  allow  him/her  to 
perforin  the  procurement  by  negotiation  vice  formal  adver- 
tisement. However,  for  procurements  exceeding  the  $10,000 
($25,000)  threshold,  the  buyer  must  either  issue  a  formal 
Invitation  For  Bid  (IFB)  or  obtain  approval  from  a  higher 
level  to  negotiate  the  procurement.  After  determining  the 
method  of  procurement,  IFB  or  negotiation,  the  process  is 
basically  the  same. 

After  the  buyer  receives  the  offers  from  prospective 
contractors,  those  offers  are  evaluated  and  contracts  are 
awarded  or  order  placed  with  the  successful  vendor.  The 
contract  documents  are  signed,  distributed,  and  filed  for 
use  by  personnel  administrating  the  contract  until  all 
action  is  completed  and  the  veniors  invoice  is  paid. 
Additionally,  regulations  require  that  these  files  be  kept 
for  a  period  of  seven  years . 

It  should  be  understood  at  this  point  that  this 
discription  has  been  highly  simplified  to  enhance  the  read- 
er's understanding.  The  regulatory  requirements  and  the 
procedural  details  dealing  with  contract  preparation,  evalu- 
ation, negotiation,  and  solicitation  in  conjunction  with 
contract  administration  can  only  be  fully  appreciated  by  an 
indepth  study  of  the  laws  and  regulations  of  government 
procurement.  Since  this  examination  is  concerned  with  the 
automation  of  the  procurement  process,  an  indepth  study  of 
this  magnitude  is  considered  beyond  the  scope  of  the 
research.  However,  a  list  cf  the  required  input,  ou-put, 
and  report  documentation  should  provide  the  reader  with  an 
appreciation  of  the  scope  of  the  procurement  orocess. 
Appendix  A  provides  a  list  of  the  major  input,  output  and, 
report  documents  required  by  these  two  Navy  activities. 


25 


D.       PROBLEM    AREAS 

In  the  early  1970s,  several  studies  of  the  government 
procurement   process      were   initiated.  This   mainly      stemmed 

from  the  1972  Report  to  Congress  from  the  Commission  on 
Government  Procurement.  Because  of  the  increased  emphasis 
placed  on  government  procurement,  the  Navy  began  to  perform 
evaluations  at  its  procurement  activities  in  order  to 
surface   and   correct   potential  problem    areas. 

One  of  the  first  problems  identified  at  the  NSCs  and 
NRCC's  was  inefficiency  due  10  highly  labor-intensive 
procurement  actions  with  relatively  little  data  processing 
support.  All  document  preparation  and  file  maintenance  was 
done  manually.  The  data  processing  support  received  by  the 
NSC  purchase  function  was  provided  Dy  a  different  organiza- 
tional component  of  the  Supply  Center.  This  required  the 
sharing  of  large-scale  equipment  which  supported  a  wide 
range  of  functions.  Although  the  NRCC's  had  more  control  of 
their  data  processing  resources,  they  were  limited  in  size 
and    capacity  [Ref.    2:    p.  4. 1-2]. 

A  second  problem  identified  was  the  lack  of  standardized 
procedures.  Although  both  activities  are  governed  by  the 
same  laws  and  regulations,  the  manner  in  which  they  inter- 
preted the  regulations  and  methods  employed  in  enforcing  the 
regulations  varied  considerably.  \  major  reason  for  this 
was  the  different  types  of  supplies  and  services  procured  by 
each  activity.  Another  problem  identified  was  the  untimely 
flow  of  information  on  the  statas  of  the  procurement 
actions.  Customer  queries  for  statas  are  handled  by  the 
buyers  who  must  divert  their  time  from  the  buying  action  to 
perform      mundane      document       searches.  This      resulted      in 

searches  being  performed  whenever  the  buyer  could  "get  to 
it"    [Ref.    2:    p.  4.1-3]. 


25 


The  inability  of  the  current  procurement  system  to 
interface  effectively  with  the  other  DOD  and  Navy  financial, 
supply,  and  contract  administration  systems  surfaced  as 
another  major  weakness.  The  majority  of  interfacing  was 
through  copies  of  contract  documents  and  other  non-machine- 
processable  media.  This  usually  resulted  in  additional 
errors  and  sometimes  the  non-reconciliation  of  financial 
accounts   and   untimely   information. 

Other  problems  identified  were  d  =  lays  in  the  preparation 
of  formal  procurement  documents  and  nanual  entry  of  procure- 
ment   data   with  a    high    incidence    of   duplication. 

As  these  problem  areas  were  identified,  NA7SUP  began  to 
understand  why  the  effectiveness  of  the  NFC3  was  dimin- 
ishing. Collectively,  the  problems  created  excessive 
response  time  in  the  processing  of  procurement  actions. 
This  lead  to  a  reduction  in  mission  performance  and  customer 
dissatisfaction.  NAVSOP,  in  1974,  initiated  action  to  auto- 
mate the  procurement  prooess  in  an  attempt  to  find  a  solu- 
tion to  their  problems.  However,  they  first  had  to  rely  on 
the    Navy's    ADP   Program. 
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III.   NAVIES  AUTOMATED  DATA  PROCESSING  PROGRAM 

A.   BACKGROUND 

As  John  Mauchly  and  J. P.  Eckert  constructed  the  first 
all -electronic  computer,  ENIAC,  in  1945,  little  could  they 
have  realized  the  total  proliferation  of  computers  within 
ths  federal  government  thirty  years  hence.  The  first  compu- 
ters installed  in  the  government  were  mainly  used  to  support 
research  projects  within  DOD.  The  first  general  purpose  or 
business  use  of  a  computer  was  by  the  Bureau  of  Census  to 
compile  the  1950  census  lata.  By  1965,  the  number  of 
general  purpose  computers  utilized  by  the  federal  government 
increased  to  2,412  with  a  data  processing  price  tag  over 
$1,132  billion.  This  significant  increase  in  volume  was 
mainly  attributable  to  the  employment  of  general  purpose 
computers  in  the  fields  of  material,  financial,  and  adminis- 
trative management.  By  1977,  there  were  over  11,000  general 
purpose  computer  systems  in  operation  within  the  government 
[Ref.  3:  p.1]. 

1  .   U.  s .  Na  vv 

A   major      user    of   computer      technology   within      DOD    is 
the    Department    of    the    Navy     (DON)  .  From    1959    to    1975,      DON 

had  spent  more  than  2.3  billion  dollars  for  Automatic  Data 
Processing  Eguipment  (ADPE)  and  had  acquired  over  1100 
general  purpose  computer  systems  to  perform  logistic  and 
administrative  functions.  As  of  April  1932,  DON  had  a  total 
of  2728  systems  and  approximately  14,634  personnel  associ- 
ated with  the  operation  and  maintenance  of  those  systems. 
The  DON  1933  fiscal  year  budget  included  1.035  billion 
dollars  for  the  acquisition  and  maintenance  of  ADP  systems 
[Ref.    4]. 
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Forecasting  tha  future  demand  on  computer  systems, 
the  DON  established,  in  1959,  an  Automatic  Data  Processing 
Program  to  control  the  valuable  data  processing  resources. 
The  program  was  and  is  today  a  compilation  of  Navy  policies, 
objectives,  plans,  procedures,  and  principles  for  managing 
ADP  resources.  The  program  is  further  intended  to  enhance 
tha    Navy   capabilities      in   the  computer    field.  It    provides 

general  guidance  to  Navy  components  for  technical  advance- 
ment and  effective,  efficient,  and  economical  use  of 
computer   equipment    and  techniques   [Raf.    5:    p.1]. 

The  program's  general  guidance  presents  principles 
for  long  range  development  of  the  Navy's  data  processing 
capabilities  as  well  as  exploitation  of  computer  technology, 
telecommunications,  and  management  science  techniques.  The 
program  is  headed  by  the  Deputy  Under  Secretary  of  the  Navy 
(Financial  Management)  who  is  designated  the  Senior  Policy 
Official    (SPO)         for    ADP.  The   Chief      of    Naval      Operations 

(OP-9U2)  is  "dual-hatted"  as  the  Director,  Department  of  the 
Navy    ADP    Management     (DIR    DDN    ADPM)  . 

2 •      Objectives    and  Prin cities   of    the    Proqram 

THe   Navy's      ADP   program      objectives  were      officially 

established   through      the    promulgation    of      a  general      plan    by 

the  Secretary  of  the  Navy  (SECNAV)  in  1959.  The  major  objec- 
tives   outlined   by   that   plan    were: 

1.  The  combining  of  the  automated  management  information 
systems  to  form  an  aggregated  system  termed,  "a 
Department   of   the   Navy   management    information   system," 

2.  The  systematic  evoliticn  and  application  of  automatic 
data  processing  equipment  and  associated  techniques  in 
improving  information  flow  to  and  from  management  with 
optimal   uniformity,    z ompa tabill ty ,    and   responsiveness, 
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3.  The  development  and  exploitation  of  automatic  data 
processing  equipment  and  related  advanced  scientific 
techniques,  and 

4.  The  orderly  development  of  standardization  to  improve 
information  interchange  [  Ref  •  5:  p.  2]. 

Included  in  the  general  plan  were  the  policies, 
principles,  concepts,  and  procedures  to  be  followed  to 
ensure  proper  implementation  of  program  objectives  by  the 
various  Navy  organizations.  It  provided  major  stages  of 
system  development  and  detailed  instructions  for  conducting 
planning  and  feasibility  studies.  Further  guidance  was 
provided  concerning  the  policy  of  system  design,  acquisi- 
tion, installation,  and  conversion  of  ADP  systems.  In  addi- 
tion, J-he  plan  outlined  general  principles  dealing  with  the 
need  for: 

1.  Preparing  economic  analysis  to  determine  benefits  of 
automation  and  its  impact  on  direct  and  indirect,  cost, 

2.  Exploiting  the  full  capabilities  of  available  equip- 
ment and  the  management  sciences, 

3.  Automating  applications  which  have  a  legitimate 
history  and  purpose  with  consistency  and  prudent 
speed,  and 

4.  Continuously  anticipating  and  implementing  reorganiza- 
tion [Ref.  5:  p. 2]. 

By  1965,  the  growth  in  computer  technology  and 
widespread  use  of  computers  by  the  government  began  to 
create  new  problems,  many  relating  to  the  rapid  technolo- 
gical changes  in  the  ADP  field.  In  an  attempt  to  deal  with 
these  problems  and  "fix  responsibilities  within  the  govern- 
ment for  coordinating  purchase,  lease,  maintenance,  opera- 
tion, and  utilization  of  ADPS  by  federal  departments  and 
agencies".  Congress  passed  Public  Law  39-306,  commonly  known 
as  the  Brooks  Bill,  on  October  31,  1965. 
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After  the  passage  of  the  Brooks  Bill,  SECNAV  reaf- 
firmed the  objectives  of  the  Navy»s  ADP  program  through  the 
issuance  of  SECNAV  Instruction  10462. 7B  in  March  of  1966. 
This  instruction  reiterated  the  general  concepts,  purpose, 
and   principles   previously   addressed    in    1959. 

By  1970,  DOD  began  to  stress  improved  management  of 
the  use  of  ADP  resources  by  the  various  Military 
Departments.  Because  of  this  newly  kindled  interest  by  DOD, 
DOM    modified      their   ADP    program.  They   began      to    emphasize 

better  planning,  costing,  and  control  of  system  development. 
At  the  same  time,  the  major  program  objectives  became  more 
generalized  stating  the  need  for  the  exploitation  and  cost- 
effective  use  of  automated  data  processing  in  addition  to 
effecient  acquisition  and  management  of  its  resources 
[fief,    5:    p-2]. 

As  more  attention  was  focused  on  the  utilization  of 
ADP  resources,  the  rules  and  regulations  that  governed  those 
resources   began    to    multiply. 

B.       LAMS    AND    REGULATIONS 

1 •      h   Federal   Law 

Public  Law  89-306  (Brooks  Bill)  was  the  first 
substantial  attempt  to  provide  legal  guidance  to  the  govern- 
ment for  the  economic  and  efficient  utilization  of  ADP 
resources.  The  bill  stipulated  that  administrative  responsi- 
bility would  be  divided  among  three  separate  agencies.  The 
General  Services  Administration  (GSA)  in  a  major  role,  was 
given  authority  to  acquire,  operate,  fund,  and  dispose  of 
ADP  items  addressed  in  the  legislation.  Additionally,  GSA 
was  directed  to  act  as  the  "day-  to-day"  manager  of  all  ADP 
resource  acquisitions  [Raf.  6:  p-2].  The  Office  of 
Management  and  3udget   (OM3)   was  given  a   supervisory  role. 
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directed  toward  providing  guidance  to  the  federal  agencies 
en  issues  of  policy.  They  were  also  tasked  with  the  respon- 
sibility of  resolving  any  disputes  arising  under  the  bill. 
The  Department  of  Commerce  was  charged  with  providing  any 
technical  and  scientific  advisory  service  relating  to  ADP 
systems. 

The  bill  provided  specific.  guidance  to  GSA  in 
executing   ^heir    responsibilities.    They    were: 

1.  GSA  is  given  sole  procurement  authority  for  ADPE 
(Section    1 1 1  (e)  )  . 

2.  GSA  is  permitted  to  delegate  its  procurement  authority 
to  an  agency,  either  :n  a  case-by-case  basis  or 
blanket   delegation    (Section    111(b)  2). 

3.  GSA  is  to  provide  regulation-  for  reutilizaticn  of 
ADPE    within   the   government    (Section    111(b)  11). 

4.  The  bill  is  applicable  to  all  federal  agencies  and  not 
the   private   sector    (Section    111(a)). 

5.  GSA  will  control  an  ADP  revolving  fund  available  to 
agencies  without  fiscal  year  limitations  but  reimbur- 
sable  to   GSA    (Section    111(c)). 

5.  GSA  is  prohibited  from  interfering  in  an  agency's  use 
of  ADPE  or  in  agency's  determination  of  its  require- 
ments   (Section    111(g)). 

After  the  enactment  of  the  Brooks  Bill,  various 
federal  agencies  began  to  formula: e  and  issue  guidance 
concerning    ADP   resources    within    their    control. 

2-      QM3   Circular    Az.ll 

OMB,  performing  their  supervisory  function,  issued 
Circular  A-71.  First,  the  circular  directed  that  0MB  be 
responsible  for  the  overall  leadership  and  coordination  of 
ADP  system  management.  Secondly,  the  circular  tasked  GSA 
to: 
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1.  Provide  Federal  Supply  Schedules  for  use  by  agencies 
in   ordering   ADPE. 

2.  Provide  technical  information  to  users  on  the  capabil- 
ities  and    performance    of   ADPE. 

3.  Ensure  the  efficient    utilization    of    ADPE. 

4.  Attempt  to  standardize  purchase  procedures  whenever 
possible. 

Finally,      the   circular   tasked  the   heads    of   the   various   agen- 
cies   with  the   responsibility   for: 

1.  Agency-wide  planning,  coordination,  and  control  of 
equipment    utilization. 

2.  Determining    ADPE  requirements. 

3.  Cost-effective  utilization  of  AD?  systems  by 
exploiting  or  merging  of  systems  across  organizational 
lines. 

3 .   GS  A  Guideline s 

Under  the  authority  granted  by  P.L.  89-306  and  OMB 
Circular  A-71,  GSA  issued  specific  guidance  dealing  with 
acquisition  and  management  of  ADP  resources  to  all  federal 
aaencies.  The  two  primary  regulations  used  as  vehicles  to 
implement  this  guidance  were  the  Federal  Procurement 
Regulation  (FPR  Section  1-4.)  and  the  Federal  Property 
Management    Regulation     (FPMP    Section    101-35    thru    101-36). 

Since  the  provisions  of  these  regulations  are  appli- 
cable to  DOD,  their  significance  to  the  management  of  the 
Navy's    ADP    program    becomes    apparent. 

a.       Federal   Procurement   Regulation 

Section  1 -4  of  the  FPR  is  totally  dedicated  to 
the  acquisition  of  ADPE,  software,  maintenance,  service,  and 
supplies.  ADPE  is  defined  by  the  FPP  as  "general  purpose 
commercially      available,  mass      produced        automated      data 
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processing  components."  However,  FPMR  defines  it  as 
"general  or  special  purpose,"  which  exhibits  just  one  of 
several  inconsistencies  found  in  GSA  guidance. 

Two  subparts  within  section  1-4  of  the  FPR, 
.1103-  General  Policies  and  1104-  Procurement  Authority, 
require  additional  explanation  due  to  their  relevance  with 
the  subject  of  this  research.  Section  1-4.1103  sets  forth 
the  general  policies  for  obtaining  35  A  approval  prior  to  the 
acquisition  of  any  ADPE.  An  agency  may  only  procure  ADPE 
when  a  soecific  delegation  of  procurement  authority  (DPA) 
has  been  granted  by  GSA.  However,  ADPE  may  be  acquired 
without  GSA  approval  provided  that: 

1.  The  ADPE  is  specifically  designed  fcr  a  specific 
application.  However,  ADPE  on  the  commercial  market 
cannot  be  acquired  under  this  exception  unless  it  is 
modified  to  such  an  extent  as  to  preclude  future  use 
of  the  equipment  for  other  purpose. 

2.  Acquisition  is  through  a  GSA  requirements  contract. 

3.  The  acquisition  cost  does  not  exceed  $50,000  [Hef.  7: 
p.  10:1-4,  1103-1]. 

On  September  8,  1978,  this  section  of  the  FPR 
was  modified  by  Temporary  Regulation  46,  "Ose  of  Small 
Purchase  Procedures  and  Schedule  Contracts  for  Automatic 
Data  Processing  (ADP)  Requirements"  * Ref .  6:  p.  A-3].  Items 
(1)  and  (2)  were  not  changed  by  the  modification;  however, 
agencies  are  now  permitted  to  acquire  ADPE  without  prior  GSA 
approval  in  the  following  additional  instances: 

1.  If  placing  an  order  against  a  GSA  schedule  contract 
given  that: 

(a)  The  order  is  within  the  terms  and  conditions 
of  the  contract, 

(b)  The  order  is  within  the  maximum  order  limitations 
of  the  contract,  and 
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(c)         The     total      purchase        price      does      not      exceed 
5300,000. 
2.      The   total      value  of      the   procurement      does    not      exceed 
$300,000    for   competitive    procurements      and    $50,000   for 
procurements    from   a   single   source. 

Section  1-4.11 04  specifies  the  procedures  for 
requesting  GSA  approval  if  the  proposed  procurement  does  not 
fit  the  above  exceptions.  The  agency  must  submit  the 
following   information: 

1.  Copies   of   the   proposed   solicitation    document, 

2.  Estimated    dollar  value    of   the    procurement, 

3.  Estimated    system  life, 

4.  Location   of  the    data    processing    facilities    involved, 

5.  The  fiscal  quarter  during  which  the  solicitation  is 
expected  to    be   released, 

6.  A    listing    of    any   unique   support    requirements, 

7.  A  statement  that  an  evaluation  has  been  made  to  ensure 
that  the  the  proposed  procurement  represents  the 
lowest   overall   cost   alternative    to   meet   the   need, 

3.      Evidence  whether   or   i ot   site   construction    is    required, 

9.  A  statement  that  the  need  to  document  ADPS  has  been 
documented, 

10.  Statement  that  all  available  resources  have  been 
screened  and  none  are  available  to  meet  the  agency's 
need,    and 

11.  A  thorough  and  compLete  justification,  if  applicable, 
of  the  requirement  for  a  sole  source  acquisition 
[Ref.    7:    p.    1-4.1104]. 

GSA  has  three  options  in  dealing  with  an  agency 
procurement  request  (APR)  .  First,  they  can  delegate  the 
authority  -^o  procure  the  AD?E  to  the  requesting  agency. 
This  is  what  was  refered  to  above  as  a  delegation  of 
procurement   authority      (DPH).        Secondly,      they   can      issue   a 
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DPA,  but  require  that  GSA  maintains  some  type  of  involvement 
in  the  acquisition.  Finally,  GSA  oar.  conduct  the  acquisi- 
tion themselves.  Irrespective  of  GSA's  option,  action  must 
be  initiated  within  twenty  working  days  or  the  requesting 
aqency   may    assume   that  a   DPA   has   been    granted. 

b.      Federal   Property   Management    Regulation 

Sections  101.35  and  101.36  provide  the  proce- 
dures pursuant  to  GSA's  function  as  the  "day-to-day"  manager 
of  all  federal  AD?  acquisitions.  The  regulation  discusses 
such  matters  as  leasing  equipment,  reutilization  of  excess 
ADPE,  Federal  Software  Exchange  Program,  and  the  ADP 
revolving  fund.  Additionally,  the  regulation  requires  that 
each  APR  for  systems  estimated  at  over  $100,003  be  accompa- 
nied with  a  well  documented  system  study.  This  study  should 
demonstrate   that: 

1.  The  functions  to  be  performed  are  essential  and 
readily  adaptable   to    automation, 

2.  An  effort  was  made  to  reduce  the  workload  of  the 
activity  before  proceeding  with  an  expansion  of 
capacity, 

3.  An  interim  upgrade,  software  modification,  or  schedule 
changes  cannot  be  accomplished  to  improve  perfor- 
mance,and 

4.  The  new  system  design  will  achieve  the  highest 
possible   effectiveness   [Sef.    8:    p.    19]. 

Although  GSA  issues  a  multitude  of  directives 
dealing  with  ADP  resources,  there  are  two  additional  docu- 
ments that  should  be  mentioned.  First,  the  Federal 
Management  Circular  provides  general  ADP  policies  to 
federal  agencies,  but  supplies  no  specific  procedures. 
Secondly,  GSA  issues  Temporary  Regulations  which  provide 
interim      changes    to   the    FPR    and    F?«R    [  Ref .    6:    p.    A-3  ]. 


36 


p 


It  is  within  the  framework  of  tha  regulations 
previously  discussed  that  DOD  and  DON  must  conduct  the 
acquisition      and      management      of   ADP      resources.  In      this 

regard,  DOD  and  DON  have  issued  a  myriad  of  instructions  and 
directives  to  provide  further  guidance  in  the  effective  and 
efficient    management    and   acquisition    of    ADP   resources. 

4  .      DOD   Guidelines 

Upon  reviewing  the  numerous  guidance  promulgated  by 
DOD ,  it  is  apparent  that  two  instructions  are  extremely 
significant      within      the      scope    cf      this      research.  These 

instructions  deal  with  the  acquisition  and  management  of  ADP 
resources. 

a-      DOD    Instruction    5100.43 

DOD  Instruction  5  100.40  entitled 

"Responsibilities  for  the  Administration  of  the  Automatic 
Data  Processing  Program",  was  issued  in  1970.  This  instruc- 
tion designated  the  Assistant  Secretary  of  Defense 
(Comptroller)  as  the  administrator  of  the  DOD  ADP  program. 
His  responsibilities  include  developing  program  policies, 
criteria,  and  standardization  of  ADP  resources  throughout 
the  Defense  Departments.  The  Service  Secretaries  were 
required  to  designate  a  Senior  ADP  Policy  Officai  (SPO)  . 
The  SPO  was  responsible  to  evaluate  ADP  systems  before 
implementation  in  hopes  of  promoting  effective  selection, 
acquisition,    and   reut ilizat ion   of   ADPE. 

b.      DOD   Directi/e   4  105.55 

DOD  Directive  4  105.55  (dated  Say  19,  1972)  enti- 
tled "Selection  and  Acquisition  of  Automatic  Data  Processing 
Resources",  established  policies  and  guidance  for  the  selec- 
tion     and      acquisition      of    ADPE,         computer      programs,         ADP 
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contractual  services,  and  supplies.  The  directive  stipulated 
that  the  decision  to  acquire  ADP  resources  will  be  contin- 
gent, on  a  well  documented  study,  demonstrating  that: 

1.  A  valid  information  requirement  exist. 

2.  The  function  or  process  to  be  performed  is  essential. 

3.  Use  of  ADP  resources  is  the  most  cost-effective  method 
for  the  performance  of  the  function. 

4.  The  ADP  system  will  be  designei  to  provide  the  highest 
practicable  degree  of  effectiveness  and  operational 
economy. 

5.  The  lowest  overall  cost  alternative  satisfying  the 
requirement  is  determined  prior  to  +he  selection  and 
acquisition  of  ADP  resources. 

Prior  to  acquiring  any  replacement  &DPE,  consid- 
eration of  automated  data  system  design  or  redesign  is 
required.  This  enables  the  services  to  exploit  the  existing 
capabilities  of  ADPE.  Use  of  commercial  sources  for  selec- 
tion and  acquisition  of  ADP  resources  is  not  permitted 
unless  sharing  or  reutilizing  existing  government  ADP 
resources  is  uneconomical  or  unsatisfactory.  The  directive 
further  requires  that  development  of  system  specifications 
and  requirements  must  be  independent  of  a  particular 
vendor's  product  to  avoid  unfair  acquisition  practices. 

Selection  of  \D?E  for  multiple  installations  is 
initiated  when  the  system  to  be  use5  is  centrally  designed, 
programmed,  and  maintained  for  installations  concerned.  The 
directive  states  that  in  this  oase,  a  prototype  installation 
will  be  selected  for  initial  systea  implementation.  The 
remaining  sites  will  not  receive  the  system  until  the  proto- 
type system  has  adequately  perforued  in  its  operational 
environment  and  has  been  reviewed  and  certified  through 
established  evaluation  criteria. 
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In  an  effort  to  promote  effective  selection  and 
acquisition  of  ADP  resources,  the  directive  required  that 
each  military  department  establish  a  prof essionally  staffed 
activity.  The   activity      would   be      tasked   with      developing 

solicitation  documents,  evaluating  vendor  proposals,  and 
performing  competitive  selection  of  ADPE  exceeding  an  esti- 
mated value  of  5200,000  if  the  equipment  was  leased  and 
5500,000  if  purchased.  Acquisition  of  ADPE  estimated  at  a 
lower  value  would  be  administered  by  the  requesting 
activity.  Additionally,         the      directive      specified      that 

service  secretaries  were  responsible  for  approving  the 
selection  of  ADP  resources.  This  authority  could  be  dele- 
gated only    on  acquisitions    estimated    below    $500,000. 

5  •      M.11  Guidelines 

Desiring  to  provide  internal  guidelines  for  review, 
approval,  and  procurement  of  ADP  resources,  the  Assistant 
Secretary  of  the  Navy  for  Financial  Management  (SPO,AD?) 
sponsored  several  instructions.  Today,  guidelines  have  been 
promulgated  for  such  things  as  data  element  and  code  stand- 
ardization, programming  language  standardization,  ADP 
sharing,  ADP  equipment  rent ilization,  and  the  management  of 
automated  data  systems  development  just  to  name  a  few.  The 
NA7DAC    (Naval      Data    Automation    Command)  Instruction    5230.2 

lists  over  40  SECNAV  (Secretary  of  the  Navy)  Instructions 
for    ADP    resource    management. 

Perhaps  the  most  important  instruction  that  influ- 
enced and  guided  the  procedure  used  to  automate  the  procure- 
ment process  of  the  NFCS  was  5ECNA7INST  5236. 1A  entitled 
"Specification,  Selection,  and  Acquisition  of  Automatic  Data 
Processing  Equipment  (ADPE)",  dated  30  April  1974.  The 
instruction  was  the  Navy's  product  of  implementing  the  ADP 
directives    provided   by  0M3,       GSA,      and    DOD.      The    instruction 
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also  delineated  the  responsibilities  of  the  DIB  DON  ADPM, 
OP-942,  and  the  Automatic  Data  Processing  Equipment 
Selection  Office  (ADPESO) . 

The  DIH  DON  ADPM  was  directly  responsible  to  the  SPO 
for  developing  and  promulgating  plans r  policies,  and  proce- 
dures with  respect  to  ADP  review  and  evaluations.  He  was 
also  designated  as  the  Source  Selection  Authority. 

ADPESO,  later  designated  ADPSD,  was  established  as  a 
direct  result  of  DODINST.  4  105.55  requiring  the  formation  of 
a  professionally  staffed  activity  within  each  service. 
Initially,  ADPESO  was  responsible  for  acquisition  of  only 
ADPE,  but  eventually  they  assumed  responsibility  for  soft- 
ware, services,  and  supplies.  They  were  also  tasked  with 
functioning  as  the  primary  DON  liaison  office  for  ADPE 
acquisition  matters. 

The  instruction  reaffirmed  the  original  program 
policy  cf  conducting  studies  prior  to  the  acquisition  of  ADP 
resources.  It  emphasized  that  developing  data  processing 
systems  and/or  acquiring  computer  equipment  must,  be  preceded 
by  studies  which  form  the  basis  for  (1)  identifying  informa- 
tion requirements,  (2)  determining  the  kind  of  system 
needed,  and  (3)  developing  specifications  to  select  and 
acquire  computer  equipment. 

The  approval  authority  and  associated  monetary 
thresholds  were  also  established  by  this  instruction.  The 
levels  of  approval  required  was  based  upon  the  monetary 
value  of  the  equipment  and  the  type  of  procurement  action 
(competitive  or  sole  source).  On  12  April  1977  these 
approval  levels  and  thresholds  were  modified  by  SSCNAVNOTE 
5230.   The  levels  and  thresholds  are  shown  by  Fiqure  3.1. 

These  then  are  the  major  instructions  and 
regulations  that  governed  the  management  and  acquisition  of 
ADP  resources  during  the  initial  stages  of  the  effort  to 
automate  the  NFCS  procurement  process. 
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Type   Approval                                    Level    1         Level    2      Level 

3 

A.    General   Purpose  ADPS 

(Sole   Source) 

Exceeds    $500,000    purchase      X 

Up   to    $500,000    purchase                                  X 

Up   to    $100,000    purchase                                                        X 

(n  on- CPU) 

B.    General   Purpose   ADPE 

(Competitive) 

Exceeds    $1M    purchase               X 

Up   to   $1H   purchase                                           X 

Up    to    $200,000   purchase                                                      X 

(non-CPUf 
Up    to    $100,000  purchase                                                      X 
(including   CPU) 

Le  ve  1    1 

Assistant    Secretary    of    the    Navy    (Financial    Managemer 

i*0 

Level   2 

Chief   of  Naval  Operations 
Director,    DON    ADP   Management 

Commandant   of   the  Marine   Corps 

Le  ve  1   3 

Deputy   Comptroller  of   the   Navy 
Director   of   Civilian   Personnel 

Chief   of   Naval   Research 

Chief   of    Naval    Material 

Chief,    Bureau   of   Medicine   and   Surgery 
Commander,    Navy    Military   Personnel    Command 
Commander    in   Chief,    U.S.    Atlantic    Fleet 

Commander    in   Chief,    U.S.    Pacific    Fleet 

Commander    in   Chief,    U.S.    Naval   Forces,    Europe 

.    — i 

Pigure  3.1 


DON   Approval   Levels   and   Thresholds   for   ADP 
(Sef.    8) 


C.       PROCESS    FOR    ACQUIRING    ADP    RESOURCES 

It  should  be  quite  evident  at  this  point  that  there  are 
two  separate  sequential  processes  for  acquiring  an  ADP 
system  within  the  Navy.  The  first  requires  that  the 
requesting  command  analyze  and  justify  the  proposed  system. 
This    involves    exhibiting   that   the   system    mee*s    an 
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operational     requirement      and      then        justification      of      the 

system's   technical      and   economical      liability.        The      Navy's 

vechicle      for      providing    justif ication      in      conjuction      with 

system      planning        is      called        an      Automated        Data      System 

Development   Plan.      The   plan    has      two    parts.        The    first   part 

develops  and     presents  tha      economic   analysis.  The   second 

part    is   a   milestone   progress   report.         Captain   Jan   Prokop   in 

his    book,        Computers    in      the   Mavyr         describes    the      plan    as 

follows: 

The  ADS  Development  plan  is  intended  to  be  a 
comprehensive,  detailed  justification  of  ADS 
development  conversion,  or  major  revision  propo- 
sals. As  such,  it  represents  the  documentation 
required  for  approval  of  such  actions.  It  must 
therefore  present  a  well-defined  proposed  course 
of  action,  with  clearly  identifiable  goals  and 
criteria  for  measuring  progress,  in  a  level  of 
detail  consistent  with  the  scope,  cost.  and 
complexity  of  the  effort  .  .  .  The  ADS 
Developement  plan  is  designed  to  answer  these 
fundamental  questions:  (1}  where  are  we?  (2)  Where 
do  we  want  to  be?  (3»  What  specific  steps  are  we 
going  to  take?  (4)  Who  is  resosnsible?  p)  What 
resources  are  required?    (6)  "Is  the   trip  worth- 

specif  ically 

sn 

which  it  will  satisfy  the  objectives  of  the  func- 
tional operations  to   be  supported   [ Ref .    9:    p.    30], 

The  level  at  which  this  plan  is  reviewed  and  approved 
depends  upon  the  cost  of  the  system  and  the  command  sponsor- 
ship or  proponent's  ability  to  generate  high-level  interest 
in  the  system.  This  is  a  very  significant  point  due  to  the 
Navy's  effort  in  the  late  70's  to  centralize  the  decisions 
regarding  ADP  policy  and  delegating  the  responsibility  for 
implementation  and  review  to  the  operational  commanders. 
Systems  receiving  high-level  review  cause  periodic  manage- 
ment reviews  of  alternatives,  incurred  cost,  and  milestones. 
This  adds  to  increased  effectiveness  in  the  acquisition  of 
ADP  resources.  On  the  other  hand,  a  low  interest-low  cost 
system  is  not  afforded  the  necessary  management  review  to 
ensure  effective  use   of   these  valuable    resources.      Sometimes 
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this      is   on?     of      the    major      reasons      that      systems   fail     to 
perform   as    originally    planned. 

Upon  approval  of  the  plans,  the  second  process  begins: 
the  evaluation  and  selection  of  the  equipment.  If  authority 
to  acquire  the  ADPE  is  granted  by  3SA  (DPA)  or  it  comes 
under  the  exceptions  previously  listed,  ADPSO  will  normally 
accomplish  the  selection  and  acquisition  of  ADP  resources 
requiring  Level  I  or  Level  II  approval.  NAVSUP  has  desig- 
nated other  activities  which  can  procure  ADPE.  These  activ- 
ities are  the  NRCC's  in  Washington,  D.C.  and  Long  Beach, 
Ca. ;  and  local  purchasing  offices  of  the  Naval  Material 
Command    (NAVMAT)     RDTS E  activities    as    designated    by   NAVMAT. 
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IV.   TH2  AUTOMATION  BFFORT 

A.   BACKGROUND 

As  perviously  mentioned  in  Chapter  One,  NAVSUP  first 
initiated  actions  to  automate  the  procurement  process  at  the 
major  NFCS  activities  in  late  1974,  However,  they  were  by 
no  means  the  first  source  to  advocate  or  use  ADP  resources 
for  the  procurement  function.  As  early  as  1961,  Howard  T. 
Lewis,  professor  emeritus  of  the  Harvard  Graduate  School  of 
Business  Administration,  when  describing  the  future  of  the 
purchasing  process  stated,  "There  will  be  big  changes  in 
dealing  with  stock,  inventory,  and  order-placing  responsi- 
bilities. This  will  come  about  is  a  result  of  better 
management  comprehension  of  the  nature  and  relationship 
between  these  activities,  and  a  greater  use  of  automatic 
data  processing"  [Ref.  10:  p. 15].  Again  in  1964,  J.  Weding 
and  C.  Diamond  addressed  the  issue  in  their  article,  "Buy  by 
Computer",  published  in  the  Harvard  Business  Review  that 
year.  They  indicated  that  relative  to  other  functions 
within  industry  and  government,  the  procurement  function  had 
consistently  been  slow  to  apply  molern  management  techni- 
gues;  therefore,  use  of  ADP  resources.  They  further  indi- 
cated that  the  procurement  organization  should  design, 
operate,  and  control  their  own  automated  system  so  as  to 
obtain  the  type  of  information  important  for  effective 
procurement  management  [Ref.  11:  p.  109]. 

In  1966,  Achelieas  Kollios  and  Joesph  Stempel  in  their 
book,  Purchasing,  and  FDP,  discussed  the  issue  of  utilizing 
EDP  in  the  purchasing  function.  In  particular,  they 
described  in  detail  the  integrate!  automated  procurement 
system   used  at   the  Aviation   Supply   Office  (ASO) .     This 
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system  basically  consisted  of  an  automated  ordering  function 
integrated  with  financial  and  inventory  management  control 
programs  [Ref.  10:  pp.  69-90]. 

On  4  September  1969r  NSC  San  Diego  implemented  an 
Automated  Local  Purchase  Support  system  (ALPS).  The  system 
consisted  of  three  major  data  filas;  (a)  FSN/Part  Number 
File,  (b)  Supplier  Name  and  Address  File,  and  (c)  Automated 
Follow-up  File.  The  systen  automated  the  purchasing  of  cont- 
rolled local  purchase  items  and  items  under  existing 
contracts  [Ref.  12:  p-8]. 

By  October  the  following  year,  the  small  purchasing 
function  at  various  NSC' s  was  being  automated  through 
locally  developed  systems.  However,  none  of  these  systems 
could  be  classified  as  a  complete  integrated  procurement 
management  information  system.  During  this  time  period,  the 
Fleet  Material  Support  Office  (FMS3) ,  having  overall  respon- 
sibility for  design  of  uniform  automated  data  processing 
procedures  and  programs,  initiated  work  on  a  system  that 
would  integrate  the  fragmented  programs  of  various  activi- 
ties into  a  comprehensive  information  system.  The  system 
would  be  divided  at  three  different  levels;  (a)  Inventory 
Control  Points,  (b)  Navy  Stock  Points,  and  (c)  Fleet  Units. 
The  development  of  one  system  applicable  to  these  three 
levels  was  considered  to  be  beyond  the  soope  of  the 
resources  available  at  that  tine  [8ef.  13:  p. 125]. 

Another  example  of  automating  a  procurement  process  was 
exhibited  by  Lieutenant  Kenneth  Patterson,  SC,  USN,  in  his 
master's  thesis  titled,  "An  Information  System  for  the 
Management  fo  Navy  Procurement".  LT.  Patterson  proposed  a 
model  that  attempted  to  solve  problems  that  procurement 
managers  have  in  accumulation,  digestion,  and  dissemination 
of  procurement  information  [Ref.  13:  p. 125].  The  system  was 
called  ASPIRE  which   is  the  acronym  for   Automated  Status  of 
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Purchase  Information  Recorded  Electronically.  It  was  er.vis- 
sioned  that  ASPIRE  would  be  a  totally  integrated  system, 
exportable  to  all  procurenent  activities.  Subsequent  to  the 
publishing  of  LT.  Patterson's  thesis,  ASPIRE  was  implemented 
at  NSC  Puget  Sound  in  Bremerton,  Washington  to  undergo 
testing. 

As  -"-he  market  for  el=ctronic  data  processing  equipment 
and  software  began  to  expand,  so  did  the  number  of  systems 
used  by  NFCS  major  activities  for  the  purpose  of  procure- 
ment. There  was  PROMIS  (Procurement  Management  Information 
System)  used  at  NSC  Charleston  and  the  WANG  system  used  a 
NRCO  Long  Beach,  in  addition  to  ASPIRE  at  NS3  Puget  Sound 
and      ALPS      at    San      Diego.  As      the    internal      and      external 

requirements  increased  and  the  benefits  of  automation  became 
known,  procurement  managers  began  to  automate  the  procure- 
ment process  at  their  activitiss.  This  led  to  various  unre- 
lated  systems,    none   of  which   were   totally    integrated. 

By  1974,  NAVSOP  began  exploring  alternatives  to  improve 
the  total  responsiveness  of  the  procurement  process  in  addi- 
tion to  resolving  the  continued  personnel  reductions 
plaguing  the  various  supply  activities.  Autoaation  of  the 
procurment  process  at  the  NFCS  activities  was  considered  to 
be  one  alternative  solution  to  their  problems.  In  recogni- 
tion of  this  alternative,  NAVSO?  initiated  several  efforts 
to  develop  an  automated  procurement  system,  refered  to  as 
APADE  (Automation  of  Procurement  and  Accounting  Data  Entry 
System)  . 

3.       APADE    I 

In  April  of  1975,  a  funded  research  and  development 
project  was  initiated  at  two  pilot  test  sites  to  de-ermine 
the  feasibility  and  cost  effectiveness  of  converting  the 
existing      manual      process    of      preparing      formal      procurement 
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documents  to  an  automated  system  utilizing  a  minicomputer. 
Tha  test  sites  selected  were  two  inventory  control  points; 
Aviation  Supply  Office  (ASO)  and  Skips  Part  Control  Center 
(SPCC)  . 

1 .  System 

The  research  and  development  effort  consisted  of 
using  Data  General  Nova  8  00  minicomputers  for  procurement 
document  preparation.  They  were  mainly  RFP's,  IFB's,  and 
purchase  award  documents.  The  system  worked  by  a  typist 
interacting  with  the  minicomputer  through  the  use  of  a  CRT 
display  unit.  The  operator  would  answer  various  guestions 
that  were  programmed  for  each  type  of  document.  The  informa- 
tion would  then  be  printed  out  by  a  large  Spectra  70 
printer.  This  printed  document  hal  to  be  reduced  before 
being  mailed  out  to  the  contractors. 

2 .  Results 

The  R&D  project  met  with  only  limited  success. 
However,  the  test  indicated  that  the  potential  existed  for 
greater  improvements  in  this  area  as  well  as  in  other  labor 
intensive   procurement    functions. 

As  and  outgrowth  of  the  RSD  project,  NAVSUP  tasked 
FMSO  in  December  1975  to  review  locally  developed  automated 
purchase  systems  at  various  MFCS  and  other  DOD  activities  in 
addition  to  commercial  soirees  fcr  possible  standardization 
and  exportation  to  the  NFCS.  The  following  is  a  list  of 
those   systems   evaluated: 

1.  PROMis      -      NSC        Charleston's      Procurement      Management 
Information    System, 

2.  ASPIRE      -      NSC      Paget         Sound's      Automated      Status      of 
Purchasing   INformation   Recorded   Electronically, 

3.  WANG    System   -    NRCO    Long    3each's    procurement    system, 
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4.  SAMMS   -   Defense    Logistics      Agency's   Standard    Automated 
Material   Management   System, 

5.  PADS      -    DARCOM's      Procurement   Automated      Documentation 
System, 

6.  CIAPS     -      Air   Force's      Customer      Integrated      Automated 
Procurement    System, 

7.  MOHAWK   Data    Sciences    21/50    System, 

8.  IBM   PROFS    Micro    Computer  System, 

9.  WANG    Data    Processing    and      Word    Processing    "Vs"    System, 
and 

10.  Xerox's    860   Word  Processing   System. 

FMSO  reported  that  these  unique  purchase  systems  were  not 
sufficiently  comprehensive  and  that  exportation  of  any 
existing   system    was   not    feasible,    even    for   a   short   term. 

Following  the  system  review,  the  need  for  the  design 
and  development  of  an  automated  procurement  system,  which 
addressed  the  total  needs  of  the  NFCS  activities  became 
apparent.  In  1976,  fiscal  year  1977  funds  were  granted  under 
the  Navy  Productivity  Enhancement  Program  to  develop  APADE 
for   system-wide   application. 

C.       APADE    II 

1  •   ££2J®££.  Initi  alizat  ion 
a.   Command  Plan  *  338 

In  April  1977,  NAVSU?  02,  Deputy  Commander  for 
Procurement  Management,  submitted  Command  ?lan#  338, 
Automation  of  Procurement  and  Accounting  Data  Entry  (APADE), 
to  the  Commander  Naval  Supply  Systems  Command. 
Subseguently,  the  plan  was  revised  and  resubmitted  on  13 
June  1977. 

The  purpose  of  the  plan  was  to  provide  manage- 
ment information  concerning  the   project.    The  overall  goal 


48 


of  the  project,  as  stated  by  the  plan,  was  to  provide  an 
automated  procurement  management  system  to  major  field 
procurement  activities.   Specifically,  the  plan  stated  that, 

The  APADE  project  will  provide  an  automated  procurement 
management" system  to  11  NAVSUP  procurement  activities 
and  18  other  major  field  purchasing  activities  with 
capabilities  for  PR/requisition  tracking,  automated 
document  preparation,  and  management  information 
reports.  The' system  will  also  have  source  data  automa- 
tion capabilities  to  enable  transfer  of  pertinent 
procurement  data  to  interfacing,  dependent  financial  and 
supply  data  systems  without  nanual  intervention. 
Overall  effect  will  be  to  improve  field  procurement 
function,  reduce  cost  of  Drocurement  operation,  reduce 
procurement  administrative  lead  time,  provida  more 
responsive  support  to  NFPS  (NFCS)  customers. 

Additionally,  the  plan  listed  the  following 
tasks  which  contribute  to  accomplishment  of  the  goal: 

1.  Finalize  system  policy  concepts, 

2.  Develop  system  design  specifications, 

3.  Identify  hardware  requirements  and   software  require- 
ments, 

4.  Develop  requirements  documentation, 

5.  Obtain  hardware  requisition  approval, 

6.  Procure  hardware/software, 

7.  Test  and  implement  at  prototype  site, 

3.   Implement  at  remaining  NAVSQP  activities,  and 
9.   Implement  at  designated  non-NAVSCJ?  activities. 
The   Command  Plan   specifically  taskad   FMSO  with   providing 
analysis,   contracting,    implementation    and   maintenance 
support   for  the   APADE   project.    &   copy  of  the   revised 
Command  Plan  is  provided  in  Appendix  B. 

Upon  reviewing  this  plan,  it  is  evident  that  the 
drafting  of  the  system  design  specifications  was  estimated 
to  take  only  one  month.  Additionally,  the  total  system 
development,  including  acquisition  of  all  applicable  hard- 
ware and  software,  was  estimated  at  six  months  with  testing 
and  implementation   at  the   prototype  site   to  be   completed 
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only  nine  months  after  project  initialization.  These  appear 
to  be  unrealist ically  short  time  franas,  given  the  myriad  of 
higher  agency  requirements  discussed  in  Chapter  III. 

b.  Organization 

Following  the  initial  submission  of  Command 
Plan*  338,  the  general  lanagement  responsibilities  within 
the  various  commands  began  to  formalize.  The  responsibility 
of  functional  sponsor  for  the  APADE  project  was  assigned  to 
Deputy  Commander  for  Contracting  Management  (NAVSUP  02). 
Project  Management  was  assigned  to  the  Deputy  Commander  for 
Plans,  Policy,  and  Programs  Deveiopnent ,  Financial  Systems 
Development  Division  (NAVSUP  0'44)  .  This  Division  would  be 
responsible  for  planning,  funding,  executing,  and  monitoring 
APADE  II  development ,  initial  implementation  and  system 
maintenance.  NAVSUP  04  1,  Programs  Control  and  Development 
Division  would  provide  support  by  scheduling  and  performing 
automated  data  processing  reviews  and  assisting  in  the 
preparation  of  various  development  plans. 

FMSO,  as  the  NA VSUPSYSCOfl  agency  responsible  for 
design  of  uniform  automated  data  processing  procedures  and 
programs,  would  perform  the  technical  management  of  the 
project.  They  would  be  specifically  tasked  with  ensuring 
that  the  Functional  Description  (FD»  and  Data  Requirements 
Document  (DRD)  accurately  reflected  the  needs  of  the 
procurement  community  mi  were  precise  enough  to  aid  in 
system  development.  Additional  responsibilities  included 
those  addressed  in  the  Command  Plan. 

c.  Systems  Policy  and  Concepts 

As  required  by  the  Coumand  Plan,  NAVSUP  02 
published  the  Systems  Policy  and  Concepts  Policy  document  in 
Aprill  1977.    The   purpose  of  this  document   was  to  outline 
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tha  requirements   for  the   APADE  II   system.    The   document 
included  the  following  main  features: 

1.  Purchase   request (PR)/   requistion   tracking/document 
control, 

2.  Automated  preparation  of  standardized,  formal  procure- 
ment documentation, 

3.  Source  data  automation, 

U.   Procurement  management  information  reporting, 

5.   Procurement  interfaca  with  existing  data  systems,  and 

5.   Real  time,  interactive  processing. 

Additionally,  this  docunent  specifically  stated 
that,  "APADE  II  will  provide  a  standardized  baseline  for 
automation  of  procurement  processes  throughtout  the  Navy 
yield  Procurement  Systea.  Due  to  the  broad  range  of  activi- 
ties involved  and  the  significant  differences  in  existing 
interrelated  (e.g.  supply  and  financial)  management  systems 
in  operation  at  various  activities,  APADE  II  design  must  be 
sufficiently  flexible  to  accommodate  such  factors"  [Ref.  14: 
P.  3-U]. 

d.   ADS  Development  Plan 

In  addition  to  the  System  Policy  and  Concepts 
document,  NAVSUP  also  initiated  work  on  the  Automated  Data 
System  Development  Plan  during  the  same  time  frame. 
However,  this  document  was  not  officially  approved  by  the 
CND  until  12  October  1977.  This  document,  as  discussed  in 
Chapter  Three,  provided  the  justification  of  the  system's 
technical  and  economical  viability. 

The  first  part  of  the  ADS  plan  was  the  Economic 
Analysis.  In  analyzing  the  automation  of  the  procurement 
process,  five  alternatives  were  considered.   They  were: 

1.   Continue  current  system, 
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2.  Contract  service, 

3.  Share  or  use  existing  facilities, 

U.      Develop  a  central  procurement  system,  and 
5.   Develop  a  uniform  minicomputer  system  at  each  proposed 
site. 

Alternative  One  was  eliminated  since  it  had 
previously  been  shown  that  the  curent  system  was  slow  and 
severly  impacted  upon  the  responsiveness  of  the  system.  The 
second  alternative  was  not  feasible  because  &PADE  II  was 
intended  for  operation  by  ncn-ADP  personnel  with  minimal 
training  required  for  system  operation.  It  was  further 
estimated  that  system  operation  wouli  not  exceed  0.5  person 
hours  per  activity  per  day.  Therefore,  it  was  not  practical 
to  contract  for  this  small  work  load.  Additionally,  it  was 
planned  that  software  maintenance  and  enhancements  would  be 
performed  by  FMSO.  Alternative  Three  was  eliainated  since 
existing  facilities  were  considered  to  be  saturated  and  did 
not  allow  the  objectives  of  the  system  to  be  met. 

Both  Alternatives  Four  (4)  and  Five  (5)  were 
considered  to  provide  equal  benefits;  however,  the  central 
procurement  system,  alternative  4,  *ould  require  additional 
manpower  for  system  operation  in  addition  to  expanded  facil- 
ities for  environmental  protection.  Alternative  4  was 
eliminated  as  the  greater  oost/equal  benefit  alternative. 

Alternative  5  consisted  of  locating  minicompu- 
ters at  12  operational  sites  plus  one  test  bed  minicomputer 
site.  The  software  would  be  unifora  across  the  procurement 
system.  The  system  would  be  adaptable  to  volume  and  varying 
personnel  requirements  at  the  sites.  Each  syst=m  would  have 
one  central  processor  with  256K  memory,  multiple  disk  units 
with  up  to  10M  bytes  of  storage,  one  magnetic  tape  unit,  one 
card  reader,  one  to  two  Line  printers,  and  up  to  '4  cathode 
ray   terminals.     The   software   developers   would   provide 
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turnkey  programming  training  and  would  be  required  only  for 
maintenance  at  FMSO.  Soma  operational  training  was  consid- 
ered to  be  necessary,  bat  the  system  could  be  operated  by 
existing  employees  currently  in  the  activities.  The  system 
would  also  produce  tapes  which  would  interface  id  other  data 
bases  affected  by  procurement  operations. 

Specifically,  APADE  II  would  be  capable  of 
interfacing  with  certain  existing  sipply,  financial,  and 
contract  administration  systems  as  necessary.  These  systems 
include:  Uniform  Automated  Data  Processing  System 
(UADPS-SP) ,  Naval  Sea  Systems  Management  Information  System 
(NAVSEAMIS) ,  Navy  Uniform  Vendors  Evaluation  Program 
(NUVEP) ,  Military  Standard  Contract  Administration  Procedure 
(MILSCAF),  Shipboard  Uniform  Automated  Data  Processing 
System  (SUADPS) ,  and  the  Integrated  Disbursing  and 
Accounting  Data  Exchange  (IDA-DX). 

The  equipment  would  require  no  special  environ- 
ment. The  CRTs  would  be  placed  on  iesk,  utilizing  existing 
work  space.  The  central  processing  unit  (CPU)  ,  disk,  and 
magnetic  tape  units  would  be  mounted  on  racks.  Line  prin- 
ters would  be  located  near  the  supervisor's  office. 
Overall,  Alternative  5  was  designed  to  meet  the  needs  of  an 
automated  procurement  system  in  the  areas  of: 

1.  Procurement    operations, 

2.  Report    generation, 

3.  Document   preparation,    and 

4.  Source    data   automation. 

The  total  cost  of  the  minicomputer  system  was 
estimated  at  $159.3  million,  shown  in  Table  I.  Based  upon 
an  inflation  rate  of  4.7  percent  per  year,  the  total  present 
value  savings  was  estimated  at  $4,265  million  over  the 
estimated  eight  year  life  of  the  system.  Payback  of  the 
investment    was   calculated   at    1.97    years. 
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P ABLE    I 

APADE    Estimated   Zost 

COST  APADE  *APADE    II-Proiect    Y<=ars  Total 

Type 

112345678 

Development 

ADP  .30000            000               .3 

Non-ADP  00000000                0 

Operational 

ADP              .09  16.5    17.3    18.2     18.9    19.3    20.8    21.3    22.8     156.3 

Non-ADP    .04  .2         .2        .2         .3         .3         .3         .3         .3         2.1 

Equipment.  11  1.4      0           0           0           3           0           0           0              1.4 


Total 

System         .24    18.4     17.5    18.4     19.2    20.1    21.1    22.1    23.1     159.8 


*   Inflated   at    4.7*0    per    year    (CHNA7MAT    ltr.    26    Dct.    1976) 

The  economic  analysis  exhibited  that  Alternative 
5  provided  for  automation  of  most  procurement  operations  at 
a   relatively   low   cost    for    aquipment,    software,    and    support. 

In  conductinq  the  econonic  analysis,  the  ADS 
develooment  plan  projectai  a  starting  date  of  the  first 
quarter  fiscal  year  1978.  Project  completion  was  estimated 
at  ADS  aDproval  plus  18  aonths.  Figure  4.1  provides  the 
planned  ADS  locations  with  installation  date  and  ADPE  to  be 
utilized. 

The  second  part  of  ths  ADS  Development  Plan 
consisted   of     the    Milestone      Progress    Report.  This   report 

exhibited  the  same  proposal  task  and  completion  dates  as  did 
Command    ?lan#    338,    Appendix    3. 
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Figure  4.1 


Site   Location    and   Installation   Estimates    (ADS 
Development    Plan) 


2-      Project   Appro  val   and   Ta s k i n J 

On    8   June    1977,      ?IA  VSUP    044    reemphasized    to    FMSO   the 
following   required    actions: 

1.  Develop   system    design    specifications    by    1    June    1977, 

2.  Award   a   contract      by    6   June    1977      to    identify   hardware 
and   software    requirements, 

3.  Identify    hardware   and    software    requirements    by    15    July 
1977, 

4.  Develop   requirements    documentation    by   30    July    1977, 

5.  Procure   hardware/software    by   3D    September    1977, 
5.      Implement    and   test    at    NSC   Oakland,    and 
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7.  Implement  at  remaining  stock  points  by  30  September 
1978. 
Additionally,  NAVSOP  044  classified  the  project  as  mandatory 
with  an  assigned  priority  of  7a.  This  priority  indicated 
that  the  APADE  effort  was  part  cf  another  major  project  that 
was  seventh  on  a  priority  list  of  projects  assigned  and 
approved  for  FMSO  during  that  fiscal  year. 

On  30  June  1977,  the  Assistant  Deputy  Commander, 
Plans,  Policy  and  Program  Development,  NAVSOP  049,  forwarded 
the  approved  Command  Plan  #  338  to  FMSO's  Commanding  Officer 
for  assignment  of  the  responsibilities  and  tasks  as  previ- 
ously mentioned.  NAVSOP  0'4  9  emphasized  the  fact  that  NAVSOP 
04  was  responsible  for  project  completion  and  sucess  of  the 
program  hinged  on  the  ability  of  NAVSOP  to  contract  for 
hardware  by  30  September  1977. 

3-   Hardware  Acquisition 

On  26  July  1977  a  delivery  order  contract  was  issued 
to  Systems  Consultants,  Inc.  (SCI)  as  a  result  of  an  unsoli- 
cited proposal  from  SCI  to  FMSD .  The  contract  specifically 
reguested  that  SCI  perform  the  following  action  if  optioned 
by  the  Government: 


in  technical   conferences   with 


'MSO 


1.  Participate 
personnel , 

2.  Review  APADE  II  design  specifications, 

3.  Develop  specific  equipment  and  system  requirements, 

4.  Perform  a  survey  of  all  available  minicomputers  suita- 
ble/capable of  performing  this  task,  and 

5.  Prepare  a  full  sysrea  specification. 

With  the  exception  of  task  five,  all  actions  were  optioned 
and  completed.  SCI  provided  a  set  of  general  system  speci- 
fication instead  of  full  system  specification  as  outlined 
above . 
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As  a  result  of  the  information  provided  by  SCI,  F3SO 
informed  NAVSUP  049  that  &PADE  II  hardware  requirements  had 
been  identified  on  16  August  1977.  The  hardware  selection 
was  based  upon  a  comparative  analysis  of  minicomputer 
systems    from   the   following    commercial    manufacturers: 

1.  Data  General, 

2.  Interdata, 

3.  Varian,  and 

4.  DEC 

The  equipment  selected  was  the  Interdata  System. 
This  system  consisted  of  a  7/32  central  processing  unit 
(256K  Bytes),  22M  Bytes  disk  drives,  600  lines  per  minute 
printers,  400  cards  per  minute  card  readers,  and  video 
display  units.  Additionally,  the  following  software  package 
was  accepted  as  part  of  the  system: 

1.  Operating  System 3S/32MI, 

2.  Compiler Cobol,  and 

3.  Utilities Telecommunications  TTAM  32. 

Data  Entry  IIRAC 
On  30  September  1977,  the  Automatic  Data  Processing 
Selection  Office  (ADPSO)  issued  a  3elivery  order  contract, 
N66032-76-D-0004,  for  the  acquisition  of  the  initial  hard- 
ware requirements  of  the  APADE  II  system.  This  was 
performed  in  accordance  with  SSCNAVINST  5236. 1A, 
Specification,  Selection  and  Acquisition  of  Automatic  Data 
Processing  Equipment.  It  was  planned  that  Interdata  proces- 
sors and  Deriphial  equipment  would  be  delivered,  installed, 
and  accepted  at  the  rate  of  two  a  month  until  all  deliveries 
were  completed.  The  first  deliveries  started  to  arrive  at 
the  prototype  and  development  sites  by  December  1977. 
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4  •   System  Development 

On  16  August  1977,  in  a  letter  to  NAVSUP  049,  the 
Commanding  Officer  of  FMSO  voiced  the  concern  that,  "we  may 
be  moving  too  quickly  and  have  not  yet  thought  out  all 
aspects  of  the  APADF  project."  One  specific  area  of  concern 
dealt  with  the  applicatioQ  software  development.  There  was 
no  indication  of  who  would  accomplish  this  effort,  i.e., 
FMSO  or  a  contractor.  FMSO*s  CO  advocated  contracting  out 
this  effort  due  to  the  lask  of  personnel  at  FMSO  with  the 
needed  experience  in  this  area.  Additionally,  he  considered 
that  application  software  development  would  take  longer  than 
the  NAVSUP  Command  plan  indicated.  He  stated  that,  "FKSO's 
personnel  estimated  a  minimum  of  six  to  eight  months  after 
award  of  a  contract  for  delivery  of  a  firs*  nodule,  with 
full  development  taking  as  long  as  fifteen  months. 

The  CO  also  addressed  the  issue  that  no  formal  plan 
had  beer,  formulated  for  maintenance  of  the  system.  He 
emphasized  that  FMSO  would  be  the  best  choice,  but  specific 
resource  requirements  would  be  difficult  to  estimate  until 
the  application  software  was  designed.  In  addition,  he 
expressed  concern  that  no  formal  plan  presently  existed  for 
incorporating  any  on-line  interfaces  via  APADE  II. 

a.   Request  for  ADP  Services 

On  2  September  1977,  FMSO  submitted  a  request 
for  ADP  services  to  the  General  Service  Administration  (GSA) 
via  GSA  form  2068,  in  accordance  with  the  Federal 
Procurement  Regulations.  (  As  described  in  Chapter  Three, 
this  is  a  request  for  a  Delegation  of  Procurement  Authority, 
DPA)  The  request  provided  the  description  of  the  minicom- 
puter system  that  had  been  agreed  upon  earlier  as  the 
minimum  equipment  configuration.  It  described  the  software 
package  being  procured  from  Interdata  and  proposed  the 
following  personnel  requirements: 
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1.  One  Team    Leader    Analyst, 

2.  Two  Computer   Systems    Analysts,    and 
3-      Four    Programmers. 

The  description  of  regussted  services  indicated 
that  FMSO  would  provide  systems  specifications  from  which  a 
computer  system  was  to  be  designed  and  programs  written  in 
addition  to  testing,  debugging,  aid  implementation  of  the 
system      at      the      first   sita.  Additionally,        the      request 

provided  the    following  system  definition: 

The  APADS  II  System  shall  consist  of  a  standard  set  of 
equipment  and  software  components  configured  according 
to  the  performance  characteristics  required  by  each  of 
the  thirteen  (13)  sites  receiving  the  system.  The  stan- 
dard equipment  and  software  set  shall  be  adaptable  for 
each  of  the  user  sites  according  to  the  definitions  and 
constraints    specified   herein. 

Further,      the   request    stipulated   that    APADE    II   would    support 

five    system   functions.      These   functions    were: 

1.  Procurement  Tracking, 

2.  Procurement  Record/History, 

3.  Document  Generation, 

'4.      Management   Information,    and 

5.      Telecommunications    Interface. 
Each    of   thes   system   requirements     ars    summarized    in    Appendix 
C. 

On  6  September  1977,  GSA  notified  FMSO  that  it 
chose  not  to  issue  a  Delagaticn  of  Procurement  Authority.  It 
further  directed  that  the  work  would  be  performed  through 
the  use  of  an  existing  AOP  Service  Contract,  negotiated  by 
GSA,  Atlanta,  for  the  Interagency  Data  System  Facility 
(IDSF)    located    in   Huntsville,    Alabama. 

Since  1967,  ISA  has  maintained  the  IDSF  at 
Huntsville  and  administered  an  ADP  service  contract  with  a 
commercial  vendor.  The  major  function  of  this  facility  is 
to   provide      a   convenient      and   economical      source   cf      systems 
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analysis  and  programming  talent  for  small  dollar  value  (less 
than  $250,000)  requirements  of  Federal  agencies,  especially 
when    a   fast   start-up   is   desired. 

IDSF      functions      as   ths      project     monitor.  In 

general,  they  provide  space,  supplies,  telephone,  etc.,  to 
the  contractor,  forward  contractor  estimates  in  response  to 
request  for  task  order  amendments,  and  verify  contractor 
charges  aaainst  the  project  task  orders.  However,  all 
Contracting  Officer  responsibilities  are  retained  by  the  GSA 
regional  office    in    Atlanta. 

It  should  be  understood,  that  these  ADP  tech- 
nical support  service  contracts  are  nothing  more  than  a  time 
and  material,  requirement  type  contract.  GSA-IDSF  orders 
labor  hours  at  a  specified  rate  and  naterial  at  cost.  This 
type  of  contract  requires  constant  monitoring  to  ensura 
efficient   and   effective   use    of   government    resources. 

On  3  September  1977,  FMSO  requested  an  estimate 
of  time  and  cost  to  perform  the  services  outlined  on  the  GSA 
Form  2068  from  IDSF  Huntsville.  The  initial  GSA  estimate 
for  the  total  APADE  II  application  software  was  approxi- 
mately $248,000  with  an  estimated  completion  date  of  April 
1979. 

b.      Memorandum  of   Onder standing 

On        21        October        1977,  a        Memorandum        of 

Understanding    (MOO)  between   GSA-IDSF    and    FMSO      was    signed. 

The  general  purpose  of  the  MOO  was  to  establish  a  working 
agreement  through  which  GSA-IDSF  would  provide  ADP  technical 
support  services  on  a  reimbursable  basis  to  FMSO. 
Specifically,  GSA-IDSF  would  issue  task  orders  to  the 
support  contractor  based  on  the  work  requirements  and  speci- 
fications submitted  by  FMSO.  Mo  single  task  order  issued  by 
GSA-IDSF   could    exceed    $250,000    for   total    support    cost.         All 
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alterations  and  modifications  of  amendments  required  prior 
approval  by  FMSO.  The  performance  period  would  be  governed 
by  the  requirements  and  specifications  for  each  individual 
task  as  prescribed  by  FMSO. 

The  initial  task  orders  to  be  accomplished  were: 

1.  System  Specifications, 

2.  Data  Base  Requirements  Document, 

3.  Test  Plan, 

4.  Program  Specifications, 

5.  Program  Coding  and  Tasting, 

6.  System  Integration, 

7.  Acceptance  Testing, 

8.  User  Manual, 

9.  Training,    and 

10.  Quality   Assurance   Program. 

A  summarization    of    each   task   is    provided    in   Appendix    D. 

It  should  be  noted  at  this  time  that  Task  One, 
System  Specifications,  was  to  be  based  upon  the  APADE  II 
Functional    Description   being  provided    by    FMSO. 

As  a  result  of  the  MOO,  a  project  order  was 
issued  on  21  October  1977  to  3SA-IDSF  for  APADE  II  applica- 
tion software  development.  Funds  amounting  to  $198,000  were 
provided  for  the  initial  ten  tasks  in  addition  to  an  evalua- 
tion of  possible  use  of  a  file  management  ,  inquiry  and 
retrival  system  and  telecommunications  package,  TAPS 
(Terminal  Application  Processing  System)  for  use  in  APADE 
II.  System  predesigr.  and  software  evaluation  was  initiated 
under  task  orders  H587  and  H538  by  Potomac  Research, 
Inc.(PRI),  the  GSA-IDSF  support  contractor  in  December  1977. 
Development  hardware  was  delivered  to  the  development 
contractor,        PRI,by    20      January      1978.  The   hardware      was 

finally  installed,  tested,  and  accepted  by  PRI  on  31  March 
1978. 
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c.   Modular  System  Concept 

As  early  as  July  1977,  nodular  system  develop- 
ment and  installation  was  planned  for  the  APADS  II  project. 
This  was  first  indicated  in  the  15  July  1977  preliminary 
system  design  specifications  published  by  FMSO.  The  modules 
were: 

1.  Module  I  Purchase  requisition  tracking, 

2.  Module  II  Automated  document  preparation, 

3.  Module  III  ....  Management  Information  Reports,  and 
%m  Module  IV  Interface  with  other  systems. 

On  15  December  1977,  FMSD  published  the  APADE  II 
Management  Plan  which  was  prepared  by  Computer  Data  Systems, 
Inc.  The  purpose  of  the  plan  was  to  provide  an  outline  of 
required  management  actions  and  related  milestones.  It 
would  be  used  to  plan  and  execute  APADE  II  development, 
evaluation,  operational  implementation  and  maintenance. 
This  plan  also  referenced  APADE  II  modules  in  describing  the 
implementation  plan.  Although  modilar  system  development 
appeared  in  both  of  these  documents,  no  reference  to  -his 
fact  was  made  in  the  ADS  development  plan. 

In  May  1978,  the  Functional  Description  (FD)  was 
published  by  FMSO  after  having  been  completed  under  contract 
with  Computer  Data  Systems,  Inc.  Tae  FD  indicated  that  the 
system  would  be  implemented  in  the  field  one  module  at  a 
time.  It  furnished  the  following  target  dates  for 
implementation: 

1.  Module  I  August  1973, 

2.  Module  II  November  1973, 

3.  Module  III  ....  February  1979,  and 

4.  Module  IV  April  1979. 
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d.  Module  I  Development 

The  task  orier  (H585)  under  which  Potomac 
Research,  Inc.  (PRI)  commenced  the  developement  of  APADE  II 
was  initiated  in  February  1978.  As  previously  mentioned, 
the  task  required  the  contractor  to  prepare  system  specifi- 
cations and  succeeding  deliverables  from  the  government 
provided  FD  and  DRD.  However,  these  items  were  not 
completed  by  Computer  Data  Systems,  Inc.  (CDSI)  until  15  Say 
1978.  Therfore,  PRI's  effort  during  the  interim  was  based 
on  preliminary  versions  of  these  documents  in  addition  to 
direct  meetings  between  FMSO,  PRI,  and  CDSI  personnel. 

For  the  next  four  months,  from  Fsbruary  until 
May  there  were  no  indications  of  any  problems  with  the 
development  effort.  PRI  was  reporting  their  work  perfor- 
mance every  two  weeks  by  submitting  task  order  activity 
reports  to  FMSO.  Additionally,  two  meetings  were  conducted 
between  the  contractor  and  FMSO  personnel  during  that 
period.  On  19  May  1978  PRI  indicated  that  they  were  experi- 
encing difficulty  with  the  TAPS  package  and  the  Interdate  OS 
32  editor.  This  was  also  the  first  time  that  they  reported 
the  use  of  over-time.  As  of  1 4  Julf  1978,  they  had  not  yet 
completed  system  testing  of  Module  I.  Implementation  on 
Module  I  at  the  prototype  site  was  scheduled  to  commence  on 
17  July  1978. 

e.  Prototype    Testing 

NSC  Oakland  ns  selected  as  the  prototype  test 
site  because  they  were  experiencing  sever  problems  in  the 
area  of  small  purchases.  During  that  year,  approximately  58 
percent  of  the  procurement  department's  personnel  were 
devoted  to  small  purchases.  They  were  receiving  from  2509 
to  3000  purchase  requests  per  week  for  non-standard,  low 
dollar-value    (less      than    510,000)       items.  This    eventually 
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resulted  in  a  weekly  output  of  1200  to  1500  award  documents. 
Because  of  the  manual  methods  employed  to  collect  data  on 
work  load  distribution,  buyer  production,  and  requisition 
status,  management  control  of  ths  procurement  process 
involving  this  many  requisitions  was  greatly  reduced. 
Approximately  600  customer  inquiries  were  being  received 
weekly  which  proved  to  be  a  costly  and  time-consuming  manual 
task  [Ref.  15:  p. 9]. 

Since  Module  I  was  specifically  designed  to 
provide  the  management  data  needed  to  control  and  simplify 
small  purchase  processing,  NSC  Oakland  would  provide  an 
excellent  test  of  the  module.  In  addition,  NSC  Oakland  had 
budgeted  for  the  personnel  decrease  associated  with  the 
productivity  increase  to  be  accrued  with  APADE  II  for  both 
FY  79  and  FY  80. 

Implementation  of  Module  I  was  originally  sche- 
duled from  17  July  thru  28  July  1973.  Although  implementa- 
tion was  initiated  on  17  July  1978,  it  was  not  fully 
stabilized  until  February  1979.  This  was  due  to  several 
problems.  The  implementation  suffered  a  series  of  software 
and  hardware  problems  which  required  several  cnanges  to  the 
initial  software  design  in  addition  to  requiring  more  hard- 
ware. FMSO  reported  that  the  softaars  had  to  undergo  exces- 
sive debugging  during  the  implementation  effort.  This 
entailed  many  long  hours  of  reprograraming  by  contractor 
personnel.  Another  problem  encountered  was  that  the 
GSA-IDSF  ADP  technical  support  contract  expired  on  30 
September  1978.  On  12  August  1978,  FMSO  was  informed  the 
follow-on  contract  had  been  awarded  to  Computer  Sciences 
Corporation  (CSC)  and  would  become  effective  1  October  1978. 
Although  the  majority  of  personnal  and  especially  the 
project  leader,  were  hired  by  the  new  contractor,  it  caused 
disruption  to  the  implementation  process. 
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On  2  January  1979,  the  contractor's  project 
leader  (the  only  project  leader  since  the  project  initia- 
tion) abruptly  left  the  contractor.  Only  at  that  time  was 
it  discovered  that  no  substantiating  documentation  for  any 
modules  existed.  The  project  leader  had  mentally  controlled 
all  development  efforts  and  the  application  software  without 
providing  any  written  documentation  of  his  undertakings.  It 
required  the  following  two  months  to  recover  lost  progress 
and  rebuild  system  documentation.  In  addition  to  the  docu- 
mentation, FMSO  considered  that  adequate  test  plans  and 
procedures  had  not  been  established  nor  used.  It  expressed 
that  the  majority  of  the  problems  encountered  were  discov- 
ered  on    site,    impacting  on    the   impleaentation   process. 

Overall,  the  results  of  the  problems  encountered 
were  that  prototype  testing  became  nonexistent  and  implemen- 
tation by  trial  and  error  was  the  game  plan.  By  20  February 
1979,  Module  I  of  APADE  II  had  been  implemented  at  NSC, 
Oakland.  Development  on  the  remaining  modules  continued 
under    the    MOO    with    GSA-IDSF. 

f.      Second   Test   site 

On  12  February  1979,  *:he  Officer  In  Charge  (OIC) 
of  NRCO  Washington,  D.C.  requested  that  Module  I  of  Apade  II 
be      implemented      at      his    activity.  He      stated      tha4:      NRCO 

Washington  had  an  urgent  need  for  an  improved  requisition 
tracking  system.  The  OIC  considered  that  since  the  hardware 
for  APADE  II  had  been  received  and  installed  at  his 
activity,  implementation.  of  Module  I  was  a  viable 
alternative  [  Ref .    16:    p.  1]. 

The  systems  test  plan  required  that  FMSO  recom- 
mend to  NAVStfP  044  when  a  module  was  ready  for  implementa- 
tion at  the  other  proposed  sites.  Although  this  had  not 
been    done,      it    was    decided    in   March    that    the   results    at    NSC, 
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Oakland  were  sufficiently  encouraging  to  justify  a  second 
prototype  test  at  NRCO  Washington,  D.C.  The  expansion  of 
Module  I  to  a  second  prototype  was  justified  by  emphasizing 
the  difference  in  procurenant  volume  and  type  between  a  NSC 
and   a   NRCO.  The   NRCO   mainly   deals    in    a      low   volume,      high 

dollar  value  environment  wheraas  the  NSC  deals  in  a  high 
volume,    low   dollar   value   anvironment    [  Sef •    15:    p. 11]. 

3y  the  end  of  April  1979,  CSC  had  generated  the 
Module  I  system  for  the  hardware  configuration  at  NRCO, 
Washington.  However,  no  specific  test  plan  stating  the 
goals  for  additional  testing  had  bean  developed.  Module  I 
was  implemented  at  NRCO  by  FMS3  personnel  in  May  1979 
without  assistance  of  contractor  personnel.  The  implementa- 
tion effort  proved  more  sucessful  than  had  been  experienced 
at  Oakland.  This  was  mainly  due  to  the  availability  of  a 
stablized  software  system  and  tha  vDlume  of  small  purchase 
actions  was  only  a  fraction  of  that  at  exparienced  at 
Oakland.  In  addition,  p.d  increasad  productivity  had  been 
forecasted    in   NRCO's    budgat. 

g.      Contract    Administration 

After  the  savers  problams  ancountared  during 
system  implementation  at  NSC,  Oakland,  FMSO  began  to  monitor 
both  GSA-IDSF  and  CSC  mora  closaly.  Although  the  MOrj 
claarly  held  their  responsibility  as  tasking  and  funding  tha 
project,  with  final  accaptance  authority,  FMSO  began  to 
become  more  involved  with  the  actual  contractor's  perfor- 
mance. The  following  coc raspondanca  are  seme  examples  of 
tha  increased  interest  in  administration  of  tha  contract  by 
FMSO. 

In  a  letter  dated  20  Fabruary  1977,  to  GSA-IDSF, 
tha    FMSO   project   officer    for   APADE   II    requested    t ha* : 
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1.  CSC  review  all  data  base,  system/subsystem,  and 
program  specifica4:  ions  of  Modile  I  to  ensure  proper 
documentation, 

2.  CSC  provide  complete  documentation  for  Modules  II  and 
III  for  review  and  approval  before  any  programs  are 
written, 

3.  CSC  fully  staff  the  project  as  exhibited  in  their 
estimates,    and 

4.  CSC  exercise  greater  management  control  to  assure  all 
programs   conform  to   applicable    standards. 

In  March  1979,  CSC  notified  FMSO  that  the 
revised  estimate  for  completion  of  Module  II  was  August 
1979.  Since  that  estimate  would  put  the  project  a  total  of 
nine  months  behind  the  original  schedule,  FMSO  stated  that 
CSC • s  projected  completion  date  was  unacceptable.  In  a 
letter  to  GSA-IDSF  dated  14  March  1979,  FMSO's  CO  indicated 
that  although  over  2950  man-hours  have  been  reported  to 
develop  system/subsystem  specifications,  program  specifica- 
tions and  other  documentation  on  Module  II  through  20 
January  1979,  little  progress  has  been  made  on  Module  II. 
He  reguested  that  it  be  determined  what  had  to  be  done  to 
complete  Module  II  by  May  1979.  In  addition,  as  a  result  of 
the  alleged  cost  to  date,  he  reguested  GSA  audit  man-hours 
expended   versus    amount   of   accomplishment. 

The  response  letter  from  GSA-IDSF  en  6  April 
1979,  indicated  that  0S0  was  not  required  to  report  hours 
expended  by  module  since  IS  A  issued  the  project  as  a  single 
task:  order.  Additionally,  the  estimated  completion  date  for 
Module  II  was  considered  reasonable  since  it  was  being 
developed  under  a  mere  formalized  manner  than  Module  I. 
This  was  in  reference  to  the  approvals  tha*  were  required  by 
FMS0*s   letter   dated   20  February    1979. 
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It  was  approxin ately  this  same  time  period  that 
CSC  recommended  implementation  of  Module  II  in  two  phases:  A 
and  B.  Phase  A  would  contain  those  capabilities  and  files 
considered  a  priority  for  implementation  at  NSC,  Oakland. 
Phase  3  would  contain  the  remaining  files,  document 
processing  and  the  Integrated  Disbursing  and  Accounting 
(IDA)  interface.  Module  IIA  was  estimated  to  be  completed 
by  CSC  on  31  July  1979  with  implementation  at  Oakland  in 
August  1979. 

3y  June  1979,  over  5303,000  had  been  spent  on 
the  application  software  development.  The  project  originally 
scheduled  for  an  April  19  79  completion  date  had  no  firm 
completion  date  in  sight.  Because  of  development  and  imple- 
mentation delays,  cost  overruns,  Naval  Audit  Service  recom- 
mendations and  requirements  associated  with 
multiple-activity  standard  systems,  the  CNC  requested,  "that 
all  new  APADE  II  initiatives  be  held  in  abeyance  pending  a 
comprehensive  evaluation  of  the  project"  [Ref.  17:  p.  1]. 
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7.   EVALUATION  AND  CONSTRAINTS 

A.   NAVDAC  EVALUATION  OF  APADE  II 

On  11  June  1979,  the  Chief  of  Naval  Operations  directed 
ths  Naval  Data  Automation  Command  (NAVDAC)  to  conduct  an 
evaluation  of  the  APADE  II  project.  He  further  requested 
that  the  evaluation  report  be  completed  no  later  than  12 
September  1979.  On  10  September  1979,  after  thrae  months  of 
thorough  evaluation,  NAVDAC  reported  their  findings  and 
recommendations  concerning  the  future  of  the  APADE  II 
project. 

1 .   NA VDAC  Findings 

NAVDAC's  evaluation  report  indicated  several  areas 
in  which  serious  problems  had  developed  and  contributed  to 
the  projects  current  condition.   Those  areas  were: 

1.  Initial  project  planning, 

2.  Contractor, 

3 .  Design, 

4 .  Implementation,  and 

5.  Project  monitoring. 

The  following  discussion   is  a  summary  of   each  problem  area 
as  reported  by  the  NAVDAC  evaluation  team. 

a.   Initial  Project  Planning 

Upon  reviewing  the  initial  approval  process  and 
planning  of  the  development  process,  NAVDAC  considered  that 
the  projected  schedule  was  overly  optimistic  in  that  the 
magnitude  of  the  APADE  II  project  w=s  not  fully  understood. 
Additionally,   they   considered  the   system  design   conceots 
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were  not  sufficiently  defined  to  justify  early  acquisition 
of  ADP  hardware. 

NAVDAC  also  indicated  that  a  major  failure  in 
The  early  stages  of  projact  planning  was  in  defining  the 
requirements  of  the  application  software  development 
contractor.  Specifically  the  fact  that  the  contractor 
performed  software  development  before  the  Functional 
Description  (FD)  and  Data  Requireranet  Document  (DRD)  were 
completed.  This  required  interpretation  of  the  functional 
requirements  by  the  development  contractor  and  subsequently 
resulted  in  disputes  as  to  the  consistency  between  developed 
program  and  functional  requirements.  In  addition,  the 
development  contractor  had  no  procurement  expertise  among 
his  personnel. 

Another  flaw  in  project  planning  was  a  lack  of 
detailed  test  plans  describing  what  tests  were  to  be 
conducted  and  by  whom.  The  Test  and  Implementation  Plan  did 
not  provide  for  test  data  recording,  reporting,  evaluating, 
or  approval  procedures. 

b.   Contractor 

NAVDAC  considered  the  change  of  the  GSA-IDSF  ADP 
Support  contract  from  PRI  to  CSC,  combined  with  the  abrupt 
departure  of  the  contractor's  project  leader,  significantly 
contributed  to  the  delay  in  software  develpoment .  However, 
they  indicated  that  coordination  with  and  control  of  the 
contractor  had  just  as  much  impact  :n  inhibiting  the  devel- 
opment process.  They  cited  the  failure  of  GSA  and  ?!1S0  to 
establish  intermediate  milestones  for  the  contractor  and  GSA 
to  monitor  progress  and  penalize  late  delivery  as  contri- 
buting fac+ors.  Also,  the  geographic  location  of  FMSO,  GSA, 
the  Development  Site,  and  the  Prototype  site  impeded  organi- 
zational communications.   To  this  statement,  they  referenced 
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frequent  communications  between  CSC  and  FMSO  concerning 
interpretations  of  the  FD  and  systsdt  requirements  without 
informing  GSA-IDSF.  This  led  to  veubal  changes,  additional 
labor  commitments,  contractor  claims,  and  disputes  over  the 
veracity  of  these  claims. 

c.   Design 

NAVDAC  stated  that  the  selection  of  TAPS  as  the 
file  management,  inquiry  and  retrieval  system  and  telecommu- 
nications package  restricted  APADE  II  design.  They  indi- 
cated that  designing  an  efficient  application  system  in  the 
TAPS  environment  required  an  extensive  knowledge  of  TAPS's 
capabilities  and  limitations.  TAPS  was  a  relatively  new 
product  and  both  PHI  and  CSC  had  no  prior  experience  with 
this  package.  NAVDAC  reported  that  contractor  personnel 
possessed  only  a  limited  understanding  of  ^he  Interdata  7/32 
operating   package,    OS/32HI. 

The  system  design  did  not  allow  for  any  recovery 
capability.  The  only  back-up  capability  was  provided  by 
daily   copying   of  all   data   and   index   files   to   magnetic   tape. 

NAVDAC  also  cDnsidered  that  the  system  was  being 
developed  in  an  excessively  fragmented  fashion.  Although 
the  original  four  module  approach  was  acceptable,  fragmenta- 
tion of  design  was  resulting  because  difficult  aspects  of 
certain  modules  were  being  transfers!  to  later  -nodule  devel- 
opment  or   formed   into    a   separate   module. 

NAVDAC  also  addressed  the  fact  that  no 
contractor  or  Navy  personnel  with  adequate  hardware  experi- 
ence, in  general,  and  Interdata  hardware  experience,  in 
particlular,  were  included  in  the  project's  structure. 
There  were  no  means  to  ensure  efficient  utilization  of  the 
ADPE    selected. 
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d.  Imp  Is  mentation 

One  of  the  major  probl=as  with  implementation 
was  the  decision  to  rush  Module  I  to  NSC  Oakland.  NAVDAC 
stated  that,  "  the  system  was  implemented  without  adequate 
prior  software  testing  to  satisfy  an  urgent  NSC  need  for  an 
automated  aid  to  their  small  purchasing  crisis.  Instead  of 
helping,  the  system  was  a  burden  to  NSC  management  and  a 
resource  drain  from  July  79  through  February  1979"  [ Ref -  15: 
p. 33]. 

e.  Project    Monitoring 

In  reference  to  project  uon itoring,  NAVDAC  indi- 
cated that  management  review  actions  were  not  initiated  when 
the  project  began  to  experience  problems  with  implementa- 
tion. They  further  stated  that  the  ADS  development  plan  was 
not  updated  when  the  planning  estimates  proved  inaccurate. 
Additionally,  they  cited  the  December  1977  Management  Plan 
as  no  longer  current. 

They  also  indicated  that  although  the  current 
APADE  II  project  is  over  cost  and  behind  schedule,  no 
formalized  plan  had  been  developed  to  remedy  the  problems 
and  complete  the  project.  In  addition,  APADE  II  was  an 
unfunded  requirement  for  FY  80  and  out  years  in  the 
NAVSOPSYSCOM  ADP  budget  submission. 

Overall,  NA7DAC  considered  that  the  problems 
were  of  a  common  origin:  execution  before  or  without 
adequate  planning. 

2 •   Reccmmendtions 

The  following  discussion  is  a  summary  of  the  recom- 
mendations from  NAVDAC  that  were  orsvided  to  the  CNO  on  10 
September  1979. 
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First,  NAVDAC  recommended  that  no  APADE  II  initia- 
tives (development,  acquisition,  or  implementation)  be  taken 
prior   to   completing   the   following: 

1.  A    major  revision  to   the   APADE    II    ADS    development    plan, 

2.  Performance  analysis  and  benchmark  testing  of  hardware 
configuration  at  NSC  Oakland  to  accurately  identify 
the  hardware  requirements  that  have  only  been  esti- 
mated,   and 

3.  A  review  of  the  PD/ORD  prior  to  further  development 
with    a   Design    Review    Board   performing   a   final   review. 

It  was  also  recommended  that  APADE  II  FY  80  and  FY 
81  budgeting  requirements  be  prepared  as  quickly  as  possible 
for  the  Chief  of  Naval  Material's  (CHNAVMA?)  consideration. A 
third  recommendation  was  to  continue  with  software  develop- 
ment and  documentation  through  the  completion  of  Module  IIA. 
In  addition,  it  was  recommended  to  implement  Module  IIA  at 
the  current  prototype  sites,  and  at  limited  additional 
NAVSUPSYSCOM  sites  following  CHNAVMAT  approval  of  prototype 
test    results. 

NAVDAC  s  fourth  recommendation  stated  that  AD? 
Readiness  Reviews  at  the  activities  not  reviewed  should  be 
done  and  documented  for  CHN AVMAT  approval.  Finally,  if  the 
CN3  should  ultimately  approve  continuation  of  APADE  II 
development,  the  following  additional  recommendations  were 
submitted. 

1.  Formalize    -est    and    acceptance    procedures, 

2.  Premature    implementation   shouli    be    avoided, 

3.  If  software  development  is  continued  under  contract, 
the  contractor /FMS3  relationship  should  be  more 
formalized, 

<x .  Provide  basic  and  advanced  training  in  capabilities 
and  limitations  of  TAPS  to  development  programmer/ana- 
lysts,   and 
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5.  Acquire  data  recovery  capability  prior  to  full  APADE 
II  implementation. 

B.  CNO  CONSTRAINTS 

Subsequently,  the  CND  reviewed  the  NAVDAC  report  and 
provided  recommendations  in  his  latter  dated  1  November 
1979.  This  letter  placed  a  number  of  constraints  upon  the 
APADE  II,  specifically  that: 

1.  Implementation  of  Module  IIA  would  be  restricted  to 
the  two  prototype  sites,  NSC  Oakland  and  NRCO 
Washington,  D.C.  and 

2.  There  would  be  no  further  development,  beyond  module 
IIA. 

These   two  constraints   would   remain   in  effect   until   the 
following  conditions  were  satisfied: 

1.  Submission  and  approval  of  a  new  ADS  plan  including  a 
cost/benefit  analysis  contrasting  in-house  vs 
contractor  development, 

2.  Completion  of  a  hardware  sufficiency  analysis  to 
determine  hardware  tyoe  and  size  requirements  for  each 
site, 

3.  Update  of  the  APADE  1 1  FD  and  DRD  following  a  detailed 
review  of  *-hese  documents,  and 

4.  Preparation  and  submission  of  \PADE  II  FY  80  and  FY  81 
budgetary  requirements  for  CHN&VMAT's  consideration. 

C.  SUMMARY 

The  current  redesign  effort  is  applying  the  lessons 
learned  from  APADE  I  and  II  to  a  Life  Cycle  Management 
approach  developing  a  totally  integrated  and  exportable 
automated  procurement  system.    The   modular  development  and 
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design  approach  has  been  discontinued.  The  hardware 
requirements  are  presently  being  paralleled  with  the  devel- 
opment cf  a  project  to  provide  new  hardware  to  the  major 
stock  points.  This  project  is  designated  as  Stock  Point 
Logistics  Integrated  Communications  Environment (SPLICE) . 
The  software  currently  used  will  be  utilized  only  if  it  is 
compatable  with  the  new  hardware  aid  meets  the  redesign 
requirements  statement. 

The  new  APADE  systen  will  apply  the  capabilities  of 
automated  data  processing,  automated  word  processing  and 
printing,  integrated  to  the  extent  permitted  by  current 
technology.  The  new  APADE  will  provide  a  standardized 
procurement  data  processing  system  designed  to  provide: 

1.  Document  control, 

2.  Management  and  Buyer  support  iiformation, 

3.  Automated  document  and  report  preparation,  and 
U.  Interdependent  system  support. 

As  previously  mentioned,  the  redesign  effort  is  being 
performed  under  contract  with  Bocz- Allen.  Implementation  is 
currently  estimated  for  March  1983. 
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VI.   CONCLUSIONS 

For  approximately  the  last  35  years,  the  U.S.  Navy  has 
been  imvolved  in  developing  and  implementing  automated  data 
system  (ADS)  within  their  organization.  However,  it  has 
only  been  within  the  past  few  years  that  the  Navy  has 
successfully  avoided  the  major  pitfalls  associated  with 
developing  and  implementing  these  systems. 

The  major  factors  contributing  to  improved  management 
decisions  within  ADS  development  and  implementation  are 
historical  knowledge,  improved  technology,  and  increased 
education  in  this  rapid  expanding  fisld.  This  has  lead  to  a 
change  of  philosophies  among  the  personnel  tasked  with 
development  and  implementation  of  ADS,  in  addition  to 
improved  regulations  that  provide  clear  and  concise 
guidelines  for  these  personnel. 

One  article  which  provides  an  excellent  view  of  the  ADS 
development  process  within  the  Navy  was  published  in  1976  by 
Rear  Admiral  Frank  S.  Haak.  The  article  entitled, 
"Brainware  versus  Hardware"  presented  six  major  sequential 
phases  for  the  development  of  ADS  within  the  U.S.  Navy. 
They  were: 

1 .  Planning, 

2.  Technical  Development, 

3.  Hardware  Acquisition, 

4.  Programming^ 

5.  Installation,  and 

6.  Maintenance. 

The  planning  phase  is  initiated  by  identifying  the  ADS 
in  terms  of  content,  scope,  boundaries  and  external  inter- 
faces.     This    will    lead  to   the   system's    performance 
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parameters  and  characteristics  coming  intc  focus.  At  this 
time,  alternative  concepts,  designs  and  technical  approaches 
require  evaluation  to  determine  their  feasibility  and  rela- 
tive effectiveness  in  satisfying  the  system  requirements. 
Technically  feasible  alternatives  should  then  be  subjected 
to  an  economic  analysis  tor  selecting  the  optimum  system. 
The  planning  phase  should  provide  ths  following  products: 

1.  A  well-defined  concept  for  an  automated  data  system 
capable  of  satisfying  the  particular  operational 
requirements  in  a  manner  consistent  with  established 
procedures, 

2.  An  evaluation  of  technically  feasible  alternatives  for 
implementing  the  ADS  concept  to  achieve  the  best 
possible  balance  between  capabilities  and  cost,  and 

3.  An  ADS  development  plan  which  identifies  time  sche- 
dules, resources,  and  management  measures  necessary  to 
convert  the  concept  into  an  operational  capability  via 
the  selected  development  approach  [ Ref .  18:  p-14]. 

Admiral  Haak  indicated  that  short  cuts  in  this  phase 
would  probably  increase  the  risic  of  serious  performance  and 
economic  penalties  durina  the  development,  operation,  and 
maint enanceof  the  ADS. 

Designing  the  ADS  initiates  the  technical  development 
phase.  It  requires  an  "explicit  definition,  organization, 
and  structuring  of  the  lata  system  configuration  capable  of 
performing  all  processing  functions"  [Ref.  18:  p. 15]. 
Following  the  designing  of  the  ADS,  formulation  of  detailed 
characteristics,  performance  requirements,  and  configuration 
criteria  for  a  compatible  computer  system  should  be 
completed.   Products  of  this  phase  should  include: 

1.   A  comprehensive  design  for  the  full-scale  ADS, 
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2.  A  functional  description  of  the  ADS  which  identifies 
the  manner  in  which  the  design  will  satisfy  the 
requirements  of  the  \DS  sponsor, 

3.  Detailed  specif icatis ns  for  all  data  bases,  files, 
application  programs  and  software  interfaces, 

4.  ADP  equipment  specifications  far  use  in  the  selection 
of  appropriate  general  purpose  computer  systems  for 
the  ADS,  and 

5.  A  revised  development  plan  reflecting  any  significant 
changes  and  refinements  in  the  milestones  schedules, 
resources,  requirements,  and  estimated  benefits 
presented  in  the  original  ADS  development  plan 
[Ref.  18:  p. 16] 

Opon  determining  that  new  computer  hardware  is  required, 
proposals  are  then  solicited.  The  hardware  acquisition 
phase  should  result  in  a  particular  computer  configuration 
which  has  been  thoroughly  evaluated,  tested,  and  selected  or. 
the  basis  of  both  performance  and  cost. 

The  programming  phase  is  divided  into  five  sequential 
tasks.   They  are: 

1.  Analyzing  specifications  to  identify  each  program  for 
structuring, 

2.  Coding  into  programming  language, 

3.  Preparing  test  data  and  organizing  test  routines  to 
detect  possible  errors, 

4.  Testing  each  unit,  and 

5.  Documenting  the  program.   [Ref.  13:  p. 16-18.] 

After  completing  these  five  task,  system  integration  is 
performed  by  joining  individual  programs  into  organized 
modules.  The  analysis,  coding,  test  planning,  and  testing 
is  reported  and  recorded  as  integration  is  performed.  This 
phase  should  produce  the  following  products: 
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1.  Computer      programs      which      perform      all      functions      as 
specified    in   the  ADS    requirement   statement, 

2.  Documentation   for   proper   operation      and  maintenance   of 
the   ADS,    and 

3.  Complete   set    of   test    data.      [Raf.     18:    p.    18.] 

The  installation  phase  envolvee  the  testing,  final 
acceptance  and  certification,  and  installation  of  the  ADS. 
The  tasting  demonstrates  that  the  ADS  operates  in  an  effec- 
tive and  reliable  manner  and  conforms  to  the  ADS  require- 
ments and  objectives.  Whan  a  ADS  is  designed  for  more  than 
one  site,  the  test  will  be  designed  and  conducted  as  a 
prototype   evaluation. 

The  maintenance  phase  is  the  last  phase.  It  consists  of 
the  technical  support  required  to  eliminate  programming 
errors  and  provide  systen  enhancements.  This  function  is 
usually  best  performed  by  the  activity  which  designed  and 
developed  the   system. 

Only  after  reviewing  Admiral  Haak's  article  does  a  full 
appreciation  for  the  scope  of  the  development  effort  formu- 
late. By  comparing  the  APADE  II  project  and  the  development 
process  as  outlined  above,  the  inderlying  reasons  for 
APADE's  delay  and  limited  success  beoorae  more  apparent.  The 
majority  of  the  reasons  have  been  addressed  in  NAVDAC's 
report  to  CNO.  However,  there  are  two  other  factors  which, 
in  this  researcher's  opinion,  contributed  to  the  limited 
success    of    the    project. 

Although  all  activities  within  the  procurement  process 
are  governed  by  the  same  laws  and  regulations,  each  activity 
interprets  those  guidelines  in  a  slightly  different  manner. 
In  addition,  their  procedures  for  performing  the  procurement 
process    may  vary   according    to   prescribed    local   directives. 

Admiral  Haak  stated,  "Special  care  must  be  taken  to 
define  the    detailed    procedural   content    of   a    oroposed    ADS    and 
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to  examine  its  interrelationships  with  the  functional 
systems  and  standard  operating  procedures  employed  within 
the  command.  If  the  proposed  procedures  deviate  from  some 
prescribed  standard  system,  it  is  prudent  vo  propose  a 
change  to  the  standard  or  obtain  a  waiver  from  the  appro- 
priate senior  before  proceeding.  If  the  procedures  cannot  be 
defined  in  explicit,  formal  detail,  they  simply  cannot  be 
automated  anyway"  [Bef.  18:  p. 13]. 

Functionally,  the  procurement  process  could  be  described 
in  detail;  however,  the  local  operating  procedures  utilized 
by  the  various  NFCS  activities  altered  the  process  to  meet 
individual  command  requirements.  The  ADS  was  to  be  used  by 
all  designated  activities,  not  tailored  for  each  individual 
command.  Prior  to  the  development  Df  the  ADS  for  APADE,  an 
extensive  planning  anal7sis  of  the  various  procedures 
employed  should  have  been  undertaken.  Additionally,  the 
need  to  standardize  the  procedures  among  the  users  should 
have  been  evident.  An  initial  indication  of  this  occurred 
during  FMSO's  evaluation  of  automated  systems  used  by  NFCS 
activities.  None  of  these  systems  were  exportable  because 
they  were  not  comprehensive  and  designed  in  a  different 
manner  to  suit  just  one  activities  requirements.  This  fact 
should  have  clearly  indicated  that  there  was  no  standard 
system  among  the  activities. 

The  environmental  conditions  during  the  development 
effort  of  APADE  II  also  impacted  upon  the  process.  One 
reason  previously  addressed  was  the  changing  of  policies 
within  the  Navy's  ADP  program.  The  initial  development 
efforts  were  most  likely  acceptable  because,  similar  systems 
were  being  developed  in  tie  same  manner.  However,  as  time 
progressed,  development  philosophies  began  to  be  refined  and 
a  new  method  of  ADS  development  evolved. 


80 


Another  reason  was  ths  sense  of  urgency  for  tha  automa- 
tion of  the  procurement  process.  Faced  with  increasing 
procurement  actions  and  personnel  raductions  combined  with 
the  need  for  improved  procurement  information,  APADS 
appeared  to  provided  the  best  solution  to  ovarcome  these 
problems.  In  an  effort  to  provide  this  system  to  the  activ- 
ities, management  decisions  and  planning  were  unrealisti- 
cally  expedited. 

Although  the  APADE  II  project  is  a  good  example  of  how 
net  to  develop  and  implement  an  ADS,  it  provides  valuable 
insight  for  managers  to  apply  in  davaloping  and  implementing 
future  automated  data  systams.  As  long  as  the  same  mistakes 
are  not  continually  repeated,  progress  will  ba  made  in  the 
effort  to  automate  the  procurement  process. 
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APPENDIX    A 
PROCUREMENT    INPUT,    2222111*    M2    IMPORT    DOCUMENTS 

The    following      are   examples   of   input      documents  received 
by   the   NSC's   and   NRCC's: 

1.  Standard  Form    129,    "Bidders   Hailing   List    Application", 

2.  DD   Form    633,    "Contracting    Pricing    Proposal", 

3.  DD      Form      1149,  "Requisition      and      Invoice/Shipping 
Document" , 

4.  DD  Form    1348,      "Single     Line  Item    Requisition   Document 
(Manual)", 

5.  DD      1348M,        "Single    Line      Itei      Requisition      Document 
(Mechanized)  ", 

6.  DD   Form      1348-1,      "       Single    Line      Item   Release/Receipt 
Document", 

7.  DD   Form    1348-6,    "Non-NSN   Requisition    (Manual)", 
3.      DD   Form    1594,    "Contract   Completion   Statement", 

9.  NAVCOMPT        Form        227  6,         "Request        for        Contractual 
Procurement" , 

10.  NAVSUP    Form    1153,    "Request    for    Purchase   Action", 

11.  NAVSEA    Form    4700/2,    "Job    Material    List    (JML) ", 

12.  Shipment/Performance    Notification, 

13.  Notification   of   Payment, 

14.  Letter/Message    Purchase  Request, 

15.  Marerial   Request,    and 

16.  Automated    Bid   Sheets. 

The      following   is      a      list   of      some      of   the      procurement 
output   documents   distributed   by    NSCs    and   NRCCs: 

1.  Standard  Form    18,    "    Request   for    Quotations", 

2.  Standard    Form    2  6,    "Award/Contract", 
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3.  Standard      Form       30,       "Amendment       of 
Solicitations/Modification  of  Contracts", 

4.  Standard  Form  33,  "So licitatioa ,  Offer,  and  Award", 

5.  Standard  Form  36,  "Continuation  Sheet", 

6.  Standard  Form  98,    "Notice  of   Intention   to  Make   a 
Service  Contract  and  Response  to  Notice", 

7.  Standard  Form  99  Notice  of  Award  of  Cotract", 

8.  Standard  Form  1034,   "Public  Voucher  for  Purchases  and 
Services  Other  than  Personal", 

9.  DD  Form  1155,   "Order  for  SuppLies  or  Services/Reques^. 
for  Quotations" , 

10.  DD  Form   1384,   "Transportation   Control  and   Movement 
Document" , 

11.  DD  Form   1499,   "Report  of  Individual   Contract  Profit 
Plan", 

12.  DD  Form  1594,  "Contract  Completion  Statement", 

13.  DD  Form  1501,  "Abstract  of  3id3", 

14.  DD  Form  1524,  "Pre-Award  Survey  of  Offerors", 

15.  DD  Form  1707,  "Information  to  Offerors  of  Quoters", 

16.  NAVMAT  Form  4380/1,   "Labor  Surplus/Small  Business  Set 
Aside", 

17.  Assignment  to  Contract  Administration  Activity, 

18.  Best  and  Final  Notification, 

19.  Bidder's  Lists, 

20.  Bid   Verification,     Blanket     Purchase    Agreement 
(BPA) /Basic  Ordering  Aareement  (30A)  , 

21.  Business  Clearances  (Pre  and  Post), 

22.  Buyers'  Draft  Sheet, 

23.  Navy  Chief  of  Information  (CNINFO)  New  Release, 

24.  Commerce  Business  Daily   Synopsis   (before  and   after 
award)  , 

25.  Contract  Review  Board  Approval  Request, 

26.  Cure  Notice, 
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27.  D6F    (Determination   and   Findings), 

2  8.  Letter   Contract, 

29.  Non-Personal   Services    Questionnaire, 

30.  Non-Standard   Procurement   Notification, 

3  1.  Notice   of   Intent   to   Exercise   Option, 

32.  Notice   of   Termination, 

33.  Notice  to    Unseccessf u 1  Offerors, 

34.  RAN    (Request    for   Authority    to    Megotiate), 

35.  Bequest    for   Audit, 

36.  Request   for   COTR/Ordering  Officer    Assignment, 

37.  Request    for    EFO    Compliance  Check, 

38.  Request   for   Latest   Collective   Bargaining   Agreement, 

39.  Request   for    Non-Personal   Services    Statement, 
10.  Request    for   Ordering    Data, 

41.  Request   fo   SBA    for   Certificate    of   competency, 

42.  Request    for    Sole   Source   Statement, 

43.  Request   for   Statement    of   Urgency, 

44.  Request    for   Technical    Evaluation    Factors, 

45.  Show    Cause   Letter, 

46.  Stop    Work   Order,    and 

47.  UADPS_S?   Update   Transactions. 

The   NSCs    and   NRCCs   produce    ,    among    others,    the    following 
reports : 

1.  DD   Form    350,    "Individual  Procurement    Action    Report", 

2.  DD      Form         1057,        "Monthly      Procurement        Summary      by 
Purchasing   Ofice", 

3.  NAVSUP   Form    80,    "Purchase    Statistics", 

4.  Small   and    Disadvantaged  Business    Utilization   Report, 

5.  Monthly   Procurement   Administrative    Leadtiae    Report, 
5.  Letter   Contract /Other    Unpriced    Order    Report, 

7.  Uniform   Management    Report,    and 

8.  Monthly   Procurement    3acklog   Reoort. 
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APPENDIX    B 
COMMAND   PLAN    #338 


COMMAND  PLAN  APADE 
•  REVISED  April  1977 

1.  Organizational  Element: 

Deputy  Commander,  Procurement  Management. 

2.  Goal  Statement: 

To  provide  an  automated  procurement  management  system  to  major 
field  procurement  activities. 
*  ■  .- .  .       

3.  Naval  Supply  Systems  Command  Objectives  Supported: 

Specific  Objectives  SO  (Source  Data  Automation),  35  (Improved 
Supply  Performance) ,  and  92  (Automation  of  Procurement) . 

4.  Statement  of  Significance: 

The  APADE  project  will  provide  an  automated  procurement  management 
system  to  11  NAVSUP  procurement  activities  and  18  other  major  field 
purchasing  activities  with  capabilities  for  PR/requisition  tracking,, 
automated  document  preparation,  and  management  information  reports. 
The  system  will  also  have  source  data  automation  capabilities  to 
enable  transfer  of  pertinent  procurement  data  to  interfacing,  depen- 
dent financial  and  supply  data  systems  without  manual  intervention. 
Overall  effect  will  be  to  improve  field  procurement  function,  reduce 
cost  of  procurement  operation,  reduce  procurement  administrative 
leadtime,  provide  more  responsive  support  to  NFPS  customers.     * 

5.  Means  to  Measure  Progress  Toward  Goal  Accomplishment: 

The  NAVSUP  Command  Plan  reporting  system  will  be  utilized  to 
monitor  accomplishment  of  this  goal. 

6.  Tasks  V/hich  Contribute  Toward  Goal  Accomplishment: 

a.  Finalize  Systems  Policy  Concept. 

b.  Develop  Systems  Design  Specification. 

c.  Identify  Hardware  Requirements  and  Software  Requirements. 

d.  Develop  requirements  documentation. 

e.  Obtain  Hardware  requisition  approval. 

f.  Procure  Hardware/Software. 

Enclosure  (1) 
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g.  Test  and  Implement  at  NSC  Oakland. 

h.   Implement  at  remaining  NAVSUP  commanded  activities. 

i.   Implement  at  non-NAVSUP  commanded  activities  (18  sites). 

7.  Description  of  Activity  Goals: 

FMSO  -  Provide  analysis,  contracting,  implementation  and  maintenance 
support. 

8.  Availability  of  Authority  Within  Organizational  Element  to 
Accomplish  Goal: 

For  NAVSUP  commanded  activities  no  additional  authority  is  required. 
For  non-NAVSUP  commanded  activities  authorization  will  be  coordinated 
with  NAVMAT  and  parent  SYSCOM's. 


9.  Estimated  Time  for  Accomplishments: 

NAVSUP  commanded  activities  -  18  months  after  approval. 
Non-NAVSUP  commanded  activities  -  36  months  after  approval. 

10.  Relationships  Between  This  and  Other  Goals  Submitted  by 
Organizational  Elements: 

None.    / 

/ 

11.  Resources: 


a. 


/ 
SUP  02  -  2M/Y. 
SUP  04  -  2M/Y. 

FMSO~96  -  4M/Y. 

maintenance  1M/Y  continuing. 

$1.3M  OPN  for  11  NAVSUP  activities  available  FY  77. 

$1.8M  OPN  for  18  non-NAVSUP  (POM  79). 

$50  -  75K  0$MN  $  for  contractor  support. 


^L 


-/     J 


86 


to 

O 


u 
cu 

a 


o 

00 

S3 
c 


> 
o 


E- 
U 

o 


a. 
i_ 
to 


t3 


T 


^ 


a. 
to  o 


o 

00 


os 


o 

oo  a; 


a.  tj- 

r3  rr 
00  O 


^      O  O       -V 

O,    T}-   (NLO  OS  LO    Q.tT 

^  <*  <=^z\  f-  s  r* 

--o  o      u.1  cj  a  50 


O  rr 

oo  a.  rr 

Z   =3  o 


r-. 
o 

.-4 
OS 

— 
< 

a 
u 
to 


.OS 


2 

a. 
c 


< 

2 


to 
a 
to 

a. 
o 
-j 


OS 

< 


o 

00 

a 

< 

< 
a 
< 


2 
O 

»— • 
E- 

< 
E- 


3 
O 

a 

CO 

t- 

2 

Eg 

as 
i— * 

cy 

ai 

cs 

a. 
O 


o 

OS 

a. 

a. 

< 

2 
O 


Z3 

cr 

< 

UJ 
OS 
< 

5 
cs 

< 


< 
e- 
ca 
O 


OJ 

cs 

< 

— 
o 

00 


OS 

< 

OS 

< 


o 


— 

< 
o 

u 

00 
2 

E- 

< 

E- 
2 

a 


o 

u. 
OS 
O 


to 

2 

E- 
< 

f- 

2 

u 


00 


2 
< 

o 

o 


37 


V  H 

O* 

o 

00 

o 

0a 

•  X 

CU 

cu 

to 

/\ 

< 

/■* 

1 

n 

«< 

« 

§ 

»-> 

• 

1* '  1 

>• 
.3 

1 

/ 

\ 

Ou 

1 

< 

1 

1 

3 

'* 

I 

| 

J 

«■> 

> 

Si 

00 

r» 

S3 

o\. 

■ 

•"• 

u. 

o         ■>»• 

• 

co  a.  •» 

g 

■ 

~ 

• 

M 

Z  3  o 

"" 

• 

"" 

• 

} 

u.  to 

r-» 

r»» 

V 

en 

«-« 

0£ 

cu 

< 

< 

»— i 

ci 

a 

LU 

z 
o 
F 

a. 

0 

0 

< 

O 

S3 

Of 

z 

0 

CO 

u 

cu 

CU 

cu 

< 

0 

U7 

■> 

z 

a 

< 

t— « 

a 

aa 

CO 

LU 

to 

LU 

X 

-j 

0 

-J 

E— 

^^ 

ec 

CO 

<: 

2 

5 

z 
O 

at 

< 

as 

< 

"      LU 

0 

2 

CU 

to 

•J 

LU 

Z3 

<M 

f> 

*£ 

O 

O 

•    u 

O 

0. 

u 

a. 

u 

CJ 
Cu 

co 
E- 

< 

s 

K 

O 
1— 

0. 
Z> 

> 
< 

§ 

-4 

CU 

E- 

ei 
O 

a. 
z 

5 

a. 

E- 

< 

CO 

z 

< 

Cu 

z 

E- 

< 

to 

z 

< 

CO 

z 

c— 

< 

CO 

z 

5 

0 

S3 

E- 

< 

Q 

^ 

E- 

Z 

■A 

z 

Z 

cu 

H 
Z 

E- 

Z 
CU 

E- 

z 

E- 

z 

z 

a 

C-i 

z 

1 

z 
< 

o 
u 

• 

LU 

— : 

EU 

CU 

-J 

cu 

-3 

LU 
_! 

cu 

cu 

LU 

a. 

Cu 

'   22 

£3 

gg 

(— 1 

a. 

■A 

OU 

>-* 

2 

5 
< 

0- 
O 
O 
OS 

«       1     S             3            3 

r*l 

"* 

1 

s  ! 

0 

*  1 

-• 



to 

_-_^_ 

- 

O 

o 

1  w 

OO 

o 

o 

C4 

/ 

s 

CO 

c 

cu 

< 

• 



oo 

r-» 

en 

> 
o 

. 

. 

2 

1 

o   ■* 

m 

CO.  Q.  TJ- 

^  3  o 

a,   co 

- 

p^ 

t~ 

• 

Ok 

1-t 

St! 

Q 

a. 

Ul 

< 

Q 

a 

5 

Ul 

to 

s 

H-4 

> 

o 
£3 

I-. 

Ul 

w— 

cs 

0. 

— 

oo 

=3 
00 

c< 

to 

a*s 

> 

to 

CO 

< 

< 
2 

O 

i 

o 

•   2 

O 

2 

a. 

-> 

~i 

-3 

CO 

< 

a. 

5> 

f-  ui 
2  •-< 

1 

a 

a  t- 

7 

<j 

Ul  > 

< 

Ca 

• 

—1  — 

a. 

*Cm 

a.  f- 

s 

O 

§  u 

CJ 

►H  < 

" 

< 

a; 
O 

o 

oo 

1 

1 

. 

ne 

39 


APPENDIX  C 
i£ADI  II  SYSTEM  FUNCTIONAL  REQOIBBMENIS 

Procurement  Tracking 
The  APADE  II  system  shall  provide  on-line  request  and 
retrieval  functions  to  support  tha  procurement  tracking 
process.  These  functions  shall  provide  interactive  terminal 
access  to  the  Purchase  Master  File  disk  records  giving 
information  regarding  the  general  purchase  request  status. 

Procurement  Record/History 

The  APADE  II  system  shall  support  the  functions  of 
procurement  records  and  history  by  providing  a  Purchase 
Master  File  on  disk  containing  a  record  for  each  active 
procurement  in  process.  A  Purchase  Master  File  record  shall 
be  initiated  each  time  the  Procurement  Branch  begins  a 
procurement  activity.  As  the  activity  moves  through  the 
various  stages  of  procurement,  the  corresponding  records  of 
the  Purchase  Master  File  shall  be  updated  via  local  or 
remote  interactive  CRT  and  batch  mod=s. 

Document  Generation 

The  document  generation  function  shall  imclude  a 
combination  of  on-line  interactive  CRT  data  entry  and 
periodic  baich  operations.  Specific  Navy  and  other  military 
regulations  shall  be  entered  via  zhts  function  and  scored  on 
disk  by  the  system.  This  information  shall  then  be 
available  for  retrieval  and  editing  along  with  the  entry  of 
specific  text  for  the  preparation  of  the  various  formal 
procurement  documents. 
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Management  Information 

The  management  information  function  shall  provide  a 
combination  of  interactive  on-line  data  entry  and  batch 
oriented  operations.  The  procurement  office  management 
requires  the  ability  to  request  information/data  from  the 
APAD2II  System  on  various  aspects  of  the  procurement  office 
processing  (auditing)  cycle  plus  the  ability  to  generate 
periodic  batch  reports.  The  reports  may  then  be  utilized  by 
internal  procurement  office  personnel  and  external  Navy 
commands  for  purposes  of  reviewing  each  procurement  office's 
progress,  outstanding  purchase  requests,  situations,  and 
expenditure  data. 

Telecommunication  Interface 

The  telecommunication  interface  function  shall  provide 
the  ability  for  the  APADE  II  System  to  communicate  via 
common  carrier  (telephone  facilitissi  services  with  external 
U.S.  Navy  Financial  and  Supply  computerized  Data  Systems. 
This  interface  shall  be  utilized  by  the  Navy  Procurement 
Office  for  purposes  of  exchanging  (input  or  output)  APADE  II 
data/information  with  certain  other  Navy  facilities. 
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APPENDIX  D 
4PADE  II  INITIAL  TASK  ORDERS  TO  GSA-IDSF 

Tas k  One  -  System  Specif  ic  a  tions(SS) 

The  System  Specification  is  written  to  provide  detailed 
definition  of  the  system  functions,  to  provide  ongoing 
analysis,  and  to  define  in  detail  the  facilities  to  be 
utilized  to  accomplish  the  interfaces.  All  programs 
necessary  are  described.  The  SS  shall  be  written  according 
to  NAVSDP  PUB's  506,  507,  and  508  and  as  such  will  be  based 
on  the  APADE  II  Functional  Description  (FD) .  The  SS  will  be 
reviewed  by  FMSO  for  consistency  with  the  FD.  The  approved 
SS  will  be  the  basis  for  further  system  development.  If 
modifications  are  found  to  be  appropriate  to  the  SS,  all 
such  changes  shall  be  made  by  the  development  contractor 
only  on  written  approval  by  NAVSUP. 

Task  Two  -  Data  3ase  Specifications  (DS) 

The  DS  describes  the  storage  allocation  and  data  base 
organization  that  provides  the  basic  design  data  necessary 
for  construction  of  system  files,  tables,  dictionaries  and 
directories.  The  DS  shall  be  written  according  to  NAVSUP 
PUB's  506,  507  and  508  and  as  such  shall  be  based  on  the  FD, 
RD,  SS,  and  PS.  The  DS  will  be  subject  to  FMSO  approval  and 
once  approved  all  changes  shall  be  reviewed  and  approved  by 
FMSO. 

Task  Three  -  Test  Plan 

Test  plans  will  be  written  for  two  levels  of  formal 
testing.  The  upper  level  of  test  plan  shall  be  based  on  the 
FD  objectives  and  requirements  whila  the  lower  level  shall 
be  based   on  the  SS   and  its  identified   requirements.    Th» 
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test      plan    shall      be   reviewed      and   approved      by   FMSO.  The 

Functional  Test  Plan  on  upper  level  test  plan  shall  test  the 
system  from  the  user  viewpoint  and  will  demonstrate  system 
inputs  and  outputs  at  the  user  level.  The  program  test  plan 
shall  test  the  system  from  the  maintainer  »s  viewpoint  and 
shall  demonstrate  consistency  between  delivered 

documentation   and  the    systsm  code   that    is    used. 

ffitsk    Four   -   E£23I^2L  Specification    (PS) 

The  PS  describes  the  program  design  in  sufficient  detail 
to  permit  program  production  by  the  coder.  References  for 
the  PS  are  the  FD  and  the  SS .  The  PS  shall  be  written 
according  to  NAVSUP  PUB's  5  06,  507  and  508.  The  PS  shall  be 
submitted  to  FMSO  for  review  of  consistency  with  the  SS  and 
FD.  Changes      which      do      not      effect      these      higher      level 

documents  may  be  made  by  the  development  contractor  at  his 
discretion    but   must   be  submitted   for   review   by   FMSO. 

Task    Four   -   Pro^^m   £2<i±.D.l    ar.d   Testing 

The  individual  programs  identified  in  the  PS  shall  be 
coded  in  a  structured  manner  according  to  the  design  of  the 
program    specification.  After    succassful      compilation   each 

shall  be  tested  by  a  test  designed  by  the  coder.  After 
successful  testing  the  development  contractor's  quality 
assurance  manager  shall  review  the  programmer's  notebook, 
the  code  and  test  results  to  ensure  that  '■he  code  meets  the 
PS    requirements. 

Task    Six  -    System    Integration 

The  individual  programs  will  be  integrated  into  a  unit 
and      tested   according      to      the      Program    Test      Plan.  After 

completion  the  software  program  package  and  test  result  will 
be  reviewed  by  the  development  contractors  guality  assurance 
manager.  The  system  operations  and  functions  shall  then  be 
tested   according   to   the   Functional    T=st    Plan    and    the    results 
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reported  to  FMSO  by  the  development  contractor's  quality 
assurance  manager.  Tha  Functional  rest  will  be  made  with 
FMSO    representation   present. 

Task    Seven    -  l££22£.iance   Tasting 

The  software  program  package  shall  be  installed  at  NSC 
Oakland  and  operated  by  Navy  personnel  for  a  one  month 
period.  The  Navy  shall  log  all  software  incidences  during 
the  period  and  the  development  contractor  shall  correct  any 
deficiences  and        modify  the        system  documentation 

correspondingly.  When   all     deficiances      are   corrected      an 

additional  two  week  test  shall  ba  conducted  to  ensure 
correction    of  the   30    day  tsst  deficiances. 

Task    Eight    -   H§er    Manuals 

A  complete  set  of  user  documentation  for  each 
implementation  site  (35)  shall  be  provided  by  tha 
contractor.  This  documentation  will  include  detailed  desk 
procedures  for  purchase  personnel  and  an  executive  users 
manual   for      purchase    managament    personnel.  This   exacu^ive 

manual  will  provide  summary  information  such  as  reports 
available,  options  available,  summary  outlina  for  system 
operation,    etc. 

Task    Nine   -  Training 

Training  for  the  user  and  for  the  software  maintainer 
shall      be   performed      by   the      davelopmant   contractor.  User 

training  shall  be  conducted  for  complete  operation  by 
procurement  buyers  and  clarks.  Additional  matarial  will  be 
prasented  to  guide  the  user  in  obtaining  the  full  use  of 
hardware  and      software  maintenance    support.  User   training 

shall  be  based  on  the  (Jsar  Manual  and  shall  consist  of  16 
hours      of     on-site    instruction      at      NSC-Oakland.  Software 

maintenance  training  shall  consist  of  32  hours  of  classroom 
instruction.         Software   maintenanca    training      shall   be    based 
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on   the  complete   software   program   package,    all   system 
documentation  (FD,  RD ,  SS,  DS,  PS). 

Task  Ten  -  Quality.  £ssur  arise  EL2.2i3:2! 

The  development  contractor  shall  designate  a  quality 
assurance  manager  who  shall  review  all  documentation  for 
consistency  and  completeness.  He  shall  be  responsible  for 
assuring  that  all  documents  ate  consistent  with  the  final 
product  and  shall  review  all  changasto  the  FDr  5D,  SS,  DS, 
and  PS.  He  will  prepare  the  functional  and  program  test 
plans  and  shall  review  individual  code  tests  prior  to  their 
integration  into  the  system.  He  will  perticipate  in  the 
system  testing  and  shall  prepare  test  reports  on  the 
results. 
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